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1 Introduction 

The lOA language provides notations for defining both primitive and composite I/O automata. 
This note describes, both formally and with examples, the constraints on these definitions, the 
composability requirements for the components of a composite automaton, and the transformation 
of a composite automaton into an equivalent primitive automaton. 

Section [2] introduces four examples used throughout this note to illustrate new definitions and 
operations. Section ^ treats lOA programs for primitive I/O automata: it introduces notations 
for describing the syntactic structures that appear in these programs, and it lists syntactic and 
semantic conditions that these programs must satisfy to represent valid primitive I/O automata. 
Section |4] describes how to reformulate primitive 10 A programs into an equivalent but more regular 
(desugared) form that is used in later definitions in this note. Section p] treats lOA programs 
for composite I/O automata: it introduces notations for describing the syntactic structures that 
appear in these programs, describes resortings induced by them, and lists syntactic and semantic 
conditions that these programs must satisfy to represent valid composite I/O automata. Section p^ 
describes the translation of the name spaces of component automata into a unified name space 
for the composite automaton. Section [7] shows how to expand an lOA program for a composite 
automaton into an equivalent lOA program for a primitive automaton. The expansion is generated 
by combining syntactic structures of the desugared programs for the component automata after 
applying appropriate replacements of sorts and variables. Section [8] details the expansion of the 
composite automaton introduced in Section |2] using the desugared forms developed throughout 
Sections |4|]6] and the techniques described in Section [7j Finally, Section |9] gives a precise definition 
of the resortings and substitutions used to replace sorts and variables. 

Nancy Lynch and Mandana Vaziri contributed to the design of the composition mechanisms 
described in this note. Dilsun Kaynar suggested numerous and substantial clarifications in the 
note's presentation. 



2 Illustrative examples 

We use several examples of primitive and composite automata to illustrate both the notations 



provided by lOA and also the formal semantics of lOA. We refer to Examples 2.1-2.3 throughout 



Sections pHSl Example 2.4 is relevant only to Sections p}|8 



Example 2.1 Figure 2.1 contains an lOA specification for a communication channel that can both 
drop duplicate messages and reorder messages. Type parameters for the specification, Node and 
Msg, represent the set of nodes that can be connected by channels and the set of messages that 
can be transmitted. Individual parameters, i and j, represent the nodes connected by a particular 
channel. 

Two features of this example warrant particular attention later in this note. First, the example 
uses both type and variable automaton parameters. Second, it uses the keyword const to indicate 
that the parameters i and j in the action signature are terms referring to the parameters i and j 
of the automaton, rather than fresh variable declarations. 

automaton Channel (Node , Msg: type, i, j:Node) 
signature 

input send(const i, const j, m:Msg) 
output receive (const i, const j, m:Msg) 
states contents : Set [Msg] := {} 
transitions 

input send(i, j, m) 

eff contents := insert (m, contents) 
output receive (i, j, m) 
pre m G contents 
eff contents := delete(m, contents) 

Figure 2.1: Sample automaton Channel 



Example 2.2 Figure 2.2 contains the specification for a process that runs on a node indexed by a 
natural number and that communicates with its neighbors by sending and receiving messages that 
consist of natural numbers. The process records the smallest value it has received and passes on all 
values that exceed the recorded value; if the set of values waiting to be passed on grows too large, 
the process can also lose a non deterministic set of those values. Interesting features of this example 
include the use of terms as parameters in transition definitions and a local variable representing 
an initial nondeterministic choice and temporary state local to the transition. (The keyword local, 
newly added to the lOA language, replaces and extends the keyword choose formerly used to 
introduce hidden parameters. See Section Is] for a fuller description of local parameters.) 



Example 2.3 Figure 2.3 contains the specification for another process that watches for overflow 
actions and reports those that meet a simple criterion. Interesting features of this example include 
more complicated uses of type parameters and where clauses, both in the action signature and to 
distinguish two transition definitions for a single action. 



Example 2.4 Finally, Figure 2.4 contains the specification of an automaton formed by composing 



instances of these three primitive automata. This specification relies on an auxiliary specification. 



shown in Figure 2.5 to define the term between (1, nProcesses). 



automaton P(n:Int) 
signature 

input receive (const n-1, const n, x:Int) 
output sendCconst n, const n+1, x:Int), 
overflow (const n, s:Set[Int]) 
states 

val : Int :— , 
toSend : Set [Int] := {} 
transitions 

input receive (n-1 , n , x) 

eff if val — then val := x 
elseif X < val then 

toSend := insert (val, toSend); 
val := X 
elseif val < x then 

toSend := insert(x, toSend) 
fi 
output send(n, n+1, x) 
pre X e toSend 

eff toSend := delete(x, toSend) 
output overflow(n, s:Set[Int]; local t:Set[Int]) 
pre s = toSend A n < size(s) A t C s 



eff toSend := t 



Figure 2.2: Sample automaton P 



automaton Watch (T : type , what : Set [T] ) 
signature 

input overf low (x : T , s : Set [T] ) where x G what 
output found (x:T) where x G what 
states seen : Array [T , Bool ] := constant ( false ) 
transitions 

input overflow(x, s U {x}) 

eff seen[x] := true 
input overflow(x, s) where ^(x e s) 

eff seen[x] := false 
output found (x) 
pre seen [x] 

Figure 2.3: Sample automaton Watch 



axioms Between ( Int , <) 

automaton Sys (nProcesses : Int) 

components C[n:Int]: Channel (Int, Int, n, n + 1) 
where 1 < n A n < nProcesses; 
P[n:Int] where 1 < n A n < nProcesses; 
W: Watch(Int, betweenCl, nProcesses)) 
hidden send (nProcesses , nProcesses +1 , m) 

invariant of Sys : 

V in:Int V n:Int (l<mAm<nAn< nProcesses 

=> P [m] . val < P [n] . val V P [n] . val = 0) 

Figure 2.4: Sample composite automaton Sys 



Betweend, < : T , T-^Bool ) : trait 
includes Set(T) 
introduces 

__<__ : T, T ^ Bool 

between: T, T ^ Set [T] 
asserts with x, y, z: T 

X G between(y, z) <^y<xAx<z 



Figure 2.5: Auxiliary definition of function between 



3 Definitions for primitive automata 

In order to describe syntactic manipulations of lOA programs, we introduce a nomenclature for 
their syntactic elements. We expose just those elements of an lOA program we use to describe the 



expansion of composite automata into primitive form. Section 3.1 introduces nomenclature for 



and the meaning of, syntactic structures in primitive automata. Section 3.2 examines how states 



are represented and referenced in primitive lOA programs. Sections 3.3 and |3.4| describe semantic 



conditions that must hold for an lOA program to represent a valid primitive I/O automaton. 
3.1 Syntax 



Figure 3.1 illustrates the general form of an lOA definition for a primitive I/O automaton. The 
figure exposes just those elements of an lOA program we use to describe the expansion of composite 
automata into primitive form. It does not expose the individual statements that appear in an efF 
clause. (These are treated separately in Section^) Rather the figure simply refers to the "program" 
(i.e., the complete sequence of statements) in an eff clause. 



automaton A{params ) 
assumes Assumptions 
signature 



input TT^params^^^) ■where P^^^ 



output Tr{params^;^'l) where P^^^ 
internal TT^params-^^) ■where P^,^^ 



states stateVars := initVals initially P^^^ 
transitions 



input TT^params^^^^,; local localVars,-^^^,) case tj ■where -Pj„'^. 

efF Pfogj^^i. ensuring ensuring ^^^, 
output 'K{params„;^tt^; local localVars ^^i^^) case tj where Poul,t, 

pre Pre^^i^j^, 

efF Prog^^J'tt^ ensuring ensuring ^;^t^ 
internal 'K^paranis^^^.; local localVars ^^ ^.) case tj where Pintt- 

pre Pref;;^^^^ 

efF Progtlt, ensuring ensuringf^l^^ 



Figure 3.1: General form of a primitive automaton 



Notations and writing conventions 



In Figure 3.1 params denotes the sequence of type and variable declarations that serve as the 



parameters of the automaton A. The Assumptions are LSL theories defining required properties 
for these parameters. Notations params j^l^^^ and params f^-^j^ ^,, where kind is one of in, out, or 
int, denote sequences of variables and/or terms that serve as parameters for the action vr and 
its transition definitions. The notations P^'d' ^*4t> Pilnd,t,^ P^4ind,t,^ and ensuring^i^^^^ denote 
predicates (i.e., boolean-valued expressions). The notation initVals denotes the sequence of terms 
or choose expressions serving as initial values for the state variables. If the definition of A does 
not specify an initial value for some state variable, we treat the declaration of that state variable 
as equivalent to one of the form x:T := choose t:T where true. The notation Progj.-^^ j. denotes 

a program. The notation localVars j^-^^ ^, denotes a sequence of variables. In general, a notation 
ending with an "s" denotes a sequence of zero or more elements. 

Our conventions for decorating syntactic structures throughout this paper are as follows. Su- 
perscripts refer either to automaton names or to automaton-name/action-name pairs. Automaton 
names are capitalized (e.g.. A, Ci, P). Action names are not capitalized and are either Greek letters 
(e.g., vr, TTi) or written in mono-spaced font (e.g., send). Subscripts refer to more specific restric- 
tions such as action kind (i.e., in, out, or int), transition label (e.g., ti), or origin (e.g., desug). lOA 
keywords appear in a small-bold roman font. References to other text in sample lOA programs 
appear in a mono-spaced font. Syntactic structure labels and names in general lOA programs are 
italicized. 

Syntactic elements of primitive lOA programs 

Variables in lOA programs can be declared explicitly as automaton parameters {vars , which is 
a subsequence of params^), as state variables {stateVars ), or as local variables {localVars j.-^^^ j); 
they can also be declared implicitly as post-state variables that correspond to state variables, 
post-local variables corresponding to local variables, or by their appearance in action parame- 
ters {vars^^ , which appear in params^^^) or in transition parameters {vars^^^,, which appear in 

params ^^^). Variables in lOA programs can appear in parameters, terms, predicates, and pro- 



'■] 



grams. For simplicity. Figure 3.1 does not indicate which variables may have free occurrences in 



which parameters, terms, predicates, or programs; Section 3.3 describes which can occur where. 
As an illustration, variables that occur freely in P^^"" must be in one of the sequences vars or 



A,'JT 

vars-' . 



Below, we define each labeled syntactic structure and then illustrate it using selections from 



Examples |2.1 -2.3 



Parameters 

• params is the sequence of formal parameters for A, which can be either variables or type 

parameters. We decompose params into two disjoint subsequences, one (vars ) containing 

variable declarations and the other {types ) containing type parameters (identifiers qualified 

by the keyword type). For example, params ^^ is (T:type, what : Set [T]), which consists 

of a type parameter T followed by a variable what : Set [T] . Hence types is (T:type) and 

^Q^_5 Watch jg ^^j^^^ . gg^ |-^] ^ _ 

• params f^-^j^ is the sequence of parameters for the set of actions of type kind named by tt 



in A's signature. Action parameters can be either variables or const ternisj^ For example, 

Channel, send ■ / . . , , „ \ 

paramSj^^ is (const i, const j, m:Msg). 

• paramSf^-^j^ j, is the sequence of terms serving as parameters for transition definition tj for 
actions of type kind named by tt. Whereas vr can appear at most once as the name of an 

input, output, and internal action in ^'s signature, it can have more than one transition 

, n ■,■ • 4. 4. 4. J ■ J. 1 i- T7 1 Watch, overflow ■ 

denmtion as an mput, output, and mternai action, l^or example, params^^ ^^ is 

/ , , r T\ J Watch, overflow ■ / \ 

(x, s U {x>) and params^j^^ is (x, s). 

Variables 

• As noted above, vars is the sequence of variables that are declared explicitly in params , 
that is, vars is the sequence of identifiers in params qualified by some sort other than 
typen For example, vars'^^^^^^-^ is (i:Node, j :Node). 

• varSj^-^j^ is the sequence of variable declarations (i.e., non-const parameters) in params j^-^^^. 

T-1 1 ChcLnnel,send ■ / „ \ 

l^or example, vars^^ is (m:Msg). 

• stateVars is the sequence of state variables of yl. For example, state Vars ^^^^ is (contents: Set [Msg]). 



kind,ti 



postVars is the sequence of variables for post-states of A that can occur in any ensuring 

These variables are primed versions of variables in stateVars . For example, postVars is 
(val':Int, toSend' : Set [Int] ) j^ 

is the sequence of variables that occur freely in paramsi^'^j ,. , but are not in vars . 



vars/^-^^ i IS tne sequence oi variables tnat occur ireeiy m po^rams^^^^ j., 
^P,seii 

'' out,ti 



For example, vars^'^^^^ is (x:Int), because n is in vars . 



localVars f^-^^ i is a sequence of additional local variables for transition definition tj for actions 
of type kind named vr; these variables are not listed as parameters of vr in the signature of A. 
For example, localVars ^'^^ ^^ is (t:Set [Int]). 

localPostVars j^^^^ j, is the sequence of post-local variables that name the values of local vari- 
ables after execution of P'l^ogj^^^^ ^,. These variables are primed versions of variables in 
localVars f,^^^ j, that appear on the left side of an assignment statement in the transition 
definition and that can occur in ensuring j^-^^ j,. 



^We may want to consider an alternative treatment for action parameters, similar to that for params /.-'J^j^ ^ , that 
would dispense with the keyword const and treat all action parameters as terms, rather than as a mixture of terms 
and variable declarations. The current treatment allows factored notations, such as 7r(i, j:/ni), which introduce a list 
of variables of a given sort; the alternative treatment would require unfactored notations, such as n{i:Int,j:Int), in 
which a sort quahfication applies only to the term it follows immediately. 

^When we define a sequence by selecting some members of another sequence, we preserve order in projecting from 
the defining sequence to the defined sequence. For example, if u:S precedes v.T in params^, then u:S precedes v.T 
in vars^. 

^Previously, only the primed versions of state variables that appeared on the left side of an assignment statement 

• P ssnd 

in the transition definition were allowed to appear in an ensuring clause. For example, we defined postVars^^^ j 

to be (toSend' : Set [Int] ), which did not include the variable val', because val does not appear on the left side 

of an assignment in this transition definition. The more complicated definition was intended as a safeguard against 

specifiers writing val' in an ensuring clause when there was no way the value of val' could differ from that of 

val. However, the more complicated definition did not safeguard against all such errors, because specifiers could still 

write a' .val in an ensuring clause. Hence the simpler definition appears preferable. 



Predicates 



^kind ^^ ^^^ where clause for the set of actions of type kind named by vr in j4's signature. For 
example, P^^i ' is x e what. If P^^^^^ is not specified explicitly, it is taken to be true. 

If action tt does not appear as a particular kind — input, output, or internal — in ^'s signature, 
then -Pj.j^'^ is defined to be false. 

P^j^i is a predicate constraining the initial values for A's state variables. If it is not specified 
explicitly, it is taken to be true. 

^kind t ^^ ^^^ where clause for transition definition tj for actions of type kind named by tt. 

For example, Pintz ' is ^(x e s). If Pj^^^^n. is not specified explicitly, it is taken 

to be true. If action vr does not appear as a particular kind in yl's signature, then Pj^^^j^ j, is 
defined to be false . 

^'''^kind t- ^^ ^^^ precondition for transition definition tj for actions of type kind named vr, 

where kind is out or int. For example, Pre^'^^ ^ is x e toSend. If Prej^-^^ ^, is not specified 

explicitly, it is taken to be true. For every input transition, Pre-^^^^, is defined to be true 
because transition definitions for input actions do not have preconditions. 

ensuring f^^^j^ ^ is the ensuring clause in the effects clause in transition definition tj for actions 
of type kind named vr. If ensuring j^-^^ ^, is not specified explicitly, it is taken to be true. In 
the examples, all ensuring clauses are true by defaultjj 



Programs and values 

• Progj^-^j^ J, is the program in the effects clause in transition definition tj for actions of type 
kind named vr. For example, Prog^'^^ j is toSend := t. 

• initVals is the sequence of initial values for A's state variables, which can be specified 
as either terms or choose expressions. A state variable without an explicit initial value is 
equivalent to one with an unconstrained initial value, that is, to one specified by a choose 
expression constrained by the predicate true. For example, initVals is (o, {}). 



• 



tj is an optional identifier used to distinguish transition definitions of the same kind for the 
same action vr. If there is no case clause, tj is taken to be an arbitrary, but unique labelPl 



*The keyword ensuring replaces the so that keyword, which has been removed from lOA. Formerly, so that 
was used to introduce three types of predicates in lOA: the initialization predicate for automaton state, the post-state 
predicate for transition definitions, and the loop variable predicate in for statements. This multiple use was confusing. 
Furthermore, the keyword where also introduces predicates, which led to additional confusion. In the new syntax, 
automaton state predicates are introduced by initially, post-state predicates are introduced by ensuring, and all 
other predicates (including for predicates) are introduced by where. The semantics of the clauses containing these 
predicates has not changed. 

^The case clause was introduced for use by the lOA simulator; it is not described yet in the lOA manual. 

10 



3.2 Aggregate sorts for state and local variables 

State variables 

The value (or the lvalue) of any state variable (e.g., toSend:Set [Int]) may be referenced using 
that variable (e.g., toSend) as if it were a constant operator (e.g., toSend: -^ Set[Int])r| How- 
ever, in contexts that involve more than a single automaton (e.g., simulation relations or composite 
automata), such variable references may be ambiguous. Hence lOA provides an equivalent, unam- 
biguous notation for the values of state variables. 

For each automaton A without type parameters, lOA automatically defines a sort States[A], 

known as the aggregate state sort of A, as a tuple sort with a selection operator .v:States[A] — > T 

for each state variable v of sort T. lOA also automatically defines variables A and A' of sort 
States[A] to represent the aggregate state and aggregate post-state of A. The terms A.v and A' .v 
are equivalent to references to the state variable v and to its value v' in a post-state. For example. 
States [P] = tuple of val:Int, toSend: Set [Int] , and P.val is a term of sort Int equivalent to the 
state variable val. 

If an automaton A has type parameters, the notation for its aggregate state sort is more 
complicated, because there can be different instantiations of A with different actual types, and a 
simple notation States[A] for the aggregate state sort would be ambiguous. To avoid this ambiguity, 
lOA includes the type parameters of A (if any) in the notation States[A, types ] for the aggregate 
state sort of A, and the aggregate state and post-state variables A have this sort States[A, types ]. 
For example. States [Channel, Node, Msg] = tuple of contents : Set [Msg] , and Channel. contents is 
a term of sort Set [Msg] equivalent to the state variable contents. 



As we will see in Section 5.2 including type parameters in the name of the aggregate state sort 



enables us to generate distinct aggregate state sorts for each instantiation of A. 

Local variables 

In previous editions of the language, lOA introduced hidden action parameters with the keyword 
choose appearing subsequent to the where clause. Thus, hidden or choose parameters could not 
appear in the where clause. In the course of writing this document, we discovered a need for hidden 
parameters in the where clauses of desugared input actions (see Section El). In addition, we believed 
that the ability to assign (temporary) values to hidden parameters would simplify the definitions 
of expanded transition definitions of composite automatajj We introduced local variables into 
lOA to serve both these purposes. Local variables replace and extend choose parameters. Thus, 
the keyword local replaces the keyword choose in transition definition parameter lists and local 
variables are those introduced following the keyword local in these parameter lists. 

In the new notation, the scope of local variables extends to the whole transition definition, not 
just to the precondition and effects. In addition, local variables may be assigned values in the eff 
clause. Semantically, local variables are not part of the state of the I/O automaton represented 
by an lOA program. Rather, they define intermediate states that occur during the execution of 
an atomic transitions, but are not visible externally. Therefore, local variables may not appear in 
simulation relations or invariants. 

Although local variables differ significantly from state variables in terms of semantics, their 
syntactic treatment is similar. As for state variables, lOA automatically defines an aggregate local 

® An unambiguous variable identifier can be used alone. If two variables defined in the same scope have the same 
identifier, but different sorts, their identifier may need to be qualified by their sorts 



'^In the end, our final definitions in Sections 7.6 7.9 do not to use this feature. However, the ability to assign to 



local variables was deemed useful and remains in the language. 

11 



sort, together with aggregate local and post-local variables, to provide a second, equivalent notation 
for references to local and post-local variables. For every transition definition tj for an action vr of 
type kind in automaton A, the aggregate local sort Locals[A, types^, kind, ir, tj] is a tuple sort with 

a selection operator .v:States[A] — > T for each local variable v of sort T. Furthermore, aggregate 

local and post-local variables, A and A' of sort localVarSj^-^^ ^, are defined in the scope of that 
transition definition. If there is only one transition definition for an action vr of type kind, we omit 
tj in the notation for this sort. For example, the aggregate locals sort Loca/s[P, out, overflow] is 
tuple of t:Set[Iiit], and P.t is a term of sort SetClnt] equivalent to the local variable t in the 
scope of overflow. 

Note that the automaton name A is used as the identifier for two aggregate variables in ev- 
ery transition definition: A:States[A, types ] and A:Locals[A, types , kind, 7r,tj]. As specified in 



Section 



3.3 



stateVars and localVars ^.^^^ j, must have no variables in common. Therefore, the 
aggregate sorts have no selection operators in common and there is no ambiguity. 

The initial values of local variables are constrained by the where predicate of the declaring 
transition definition. In particular, a transition kind vr(. . . ) case tj is defined only for values of its 
parameters that 

1. satisfy the where clause of that kind of vr in the signature of A, and 

2. together with some choice of initial values for its local variables, satisfy the where clause of 
the transition definition. 

A transition is enabled only for the values of its parameters and local variables for which it is 
defined and for which the precondition, if any, is satisfied. 

Thus, the initial values of local variables are chosen nondeterministically from among the values 
that meet these constraints. Local variables serve as hidden parameters with the semantics formerly 
applied to choose parameters. We provide a formal treatment of the "values of its parameters" 
and "some choice of values" at the end of Section IH 

Example 3.1 The type declarations and variables automatically defined for the sample automata 



Channel, P, and Watch are shown in Figure 3.2 



type States [Channel , Node , Msg] = tuple of cont ent s : Set [Msg] 

type States [P] = tuple of val : Int , t oSend : Set [Int ] 

type States [Watch , T] = tuple of seen : Array [T , Bool] 

type Locals [P , out , overflow] = tuple of t:Set[lnt] 

Channel: States [Channel , Node, Msg] 

P : States [P] 

Watch: States [Wat ch , T] 

P: Locals [P , out , overflow] 

Figure 3.2: Automatically defined types and variables for sample automata 



3.3 Static semantic checks 

The following conditions must be true for an lOA program to represent a valid primitive I/O au- 
tomaton. These conditions, which can be checked statically, are currently performed by ioaCheck, 
the lOA parser and static-semantic checker. 
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LOCATION OF TERM 


VARIABLES THAT CAN OCCUR FREELY IN TERM 


params^ 


vars^ 


params^^^ 


vars^, vars^i^^ 


pA,n 
^kind 


vars^, varsii^^ 


initVals^ 


vars^ 


pA 

init 


vars , stateVars 


params^^^^^ 


vars"^, vars^^^^^ 


pA,n 

kindjtj 


vars^, varsf^^^^^^, localVarsf^^^^^, 


^^'^kind,t^ 


vars , '^'^^^kind t^ localVarSf.^^^^, stateVars 


Progt^:,,^ 


vars^, varSf^-^j^^, localVars f^-^^ ^, stateVars^ 


(^'^SU™9Mnd,t, 


vars^, vars^i^^^^, localVars^^^^^^, stateVars"^, 
postVars , localPostVars f.-^^^ j. 



Table 3.1: Variables that can occur freely in terms in the definition of a primitive automaton. 
Variables listed on the right may occur freely in the syntactic structure listed to their left. 



/ No sort appears more than once in types . 

/ Each action name (e.g., vr) occurs at most three times in the signature of an automaton: at 
most once in a list of input actions, at most once in a list of output actions, and at most once 
in a list of internal actions. 

/ Each occurrence of an action name (e.g., vr) in the signature of an automaton, or in one of 
its transition definitions, must be followed by the same number and sorts of parameters. 

/ The sequences vars and varSf.-^^ of variables contain no duplicates; furthermore, no variable 
appears in both vars and vars/^-^^^ for any value of /cindrl 

/ For each transition definition tj for an action of type kind named vr, no variable appears more 
than once in the combination of the sequences vars , stateVars , postVars , varSj^^^^ ^., 

localVars^l^^^^, and localPostVars^l^^^^. 
/ For each transition definition tj for an action of type kind named tt, and for any identifier v 



and sort 5, the sequences stateVars and localVars 
v.S and v':S. 



A,-7r 
kind,L 



do not contain both of the variables 



/ Any operator that occurs in a term used in the definition of an automaton must be introduced 
by a type definition or axioms clause in the lOA specification that contains the automaton 



This restriction is designed to avoid the confusion that would result if variables in vars^.-'^^^ are allowed to hide 
or override variables with the same identifiers and sorts in vars . A stronger restriction would prohibit an identifier 
from appearing in two different variables (of different sorts) in vars and varSj.^^^; this restriction would avoid the 
need to pick a fresh variable when an instantiation of A causes two variables with the same identifier to clash by 
mapping their sorts to a common sort. However, lOA does not make this stronger restriction. 
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definition, by a theory specified in the assumes clause of the definition, or by a built-in 
datatype of lOA. 

/ Any variable that occurs freely in a term used in the definition of an automaton must satisfy 



the restrictions imposed by Table 3.1 



3.4 Semantic proof obligations 

The following conditions must also be true for an lOA program to represent a valid I/O automaton. 
Except in special cases, these conditions cannot be checked automatically, because they may require 
nontrivial proofs (or even be undecidable) ; hence static semantic checkers must translate all but the 
simplest of them into proof obligations for an automated proof assistant. These proof obligations 
must be discharged using the axioms provided by lOA's built-in types, by the theories associated 
with the type definitions and the axioms in the lOA specification that contains the automaton 
definition, and by the theories associated with the assumes clause of that definition. 

/ The sets of input, output, and internal actions in an I/O automaton must be disjoint. Thus, 
for each sequence of values for the parameters of an action named vr in the definition of an 
automaton A, at most one of -Pj^''^, Pout ^ ^^"^ PinT ^^^ ^^ true. 

Special cases arise if two of the three signature where clauses for vr are literally false or if 
two of three clauses are literally true. In the former case, the check automatically succeeds; 
in the latter, it automatically fails. 

/ There must be a transition defined for every action specified in the signature. Thus, for 
each sequence of values for the parameters of an action named vr that make -P^j^')^ true, there 
must be a transition definition tj for vr of type kind such that Pf.^!^^ j, is true for these values 
together with some values for the local variable of that transition definition. 

/ For each kind of each action vr, at most one transition definition tj can be defined for each 
sequence of parameters values. That is, for each sequence of values, Pj^^i^^ ^. can be true for 
at most one value of j. 

Special cases arise if all but one of the transition definition where clauses for a kind of an action 
are literally false or any two are literally true. In the former case, the check automatically 
succeeds; in the latter, it automatically fails. 

We define these proof obligations more formally at the end of Section [4j 
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4 Desugaring primitive automata 

The syntax for lOA programs described in Section [3] allows some flexibility of expression. However, 
when deflning semantic checks and algorithmic manipulations (e.g., composition) of lOA programs, 
it is helpful to restrict attention, without loss of generality, to lOA programs that conform to a 
more limited syntax. 



In this section, we describe how to transform any primitive lOA program (as in Figure 3.1) 



into an equivalent program (Figure 4.7) written with a more limited syntax. We describe this 



transformation in four stages. First, in Section 4.1 we show how to desugar terms that appear as 



parameters by replacing them with variables constrained by where clauses; that is, we show how 
to reformulate action and transition deflnitions so as to eliminate the use of terms as parameters. 



Second, in Section 4.2, we show how to introduce canonical parameters into desugared actions and 



transition definitions. A canonicalized action is parameterized by the same sequence of variables 



in all appearances, both in the signature and in the transition definitions. Third, in Section 4.3 



we combine all transition definitions of a single kind of an action into a single transition definition. 



Fourth, in Section 4.4 we convert each reference to a state variable x to the equivalent reference 



A.x defined in Section 3.2[ In Section 4.5 we summarize the effects of these desugarings, which are 



illustrated in Figure 4.7 Finally, in Section 4.6, we use the result of the first two transformations 



to formalize the semantic proof obligations introduced in Section [3} 

4.1 Desugaring terms used as parameters 

Signature 

We desugar const parameters for an action in ^'s signature by introducing fresh variables and 
modifying the action's where clause. For each const parameter we introduce a fresh variable and 
add a conjunct to the where clause that equates the new variable with the term that served as the 
const parameter. For example, if t is a term of sort T, then we desugar the action 



input 'iT{varS'^^ , const t) ■where P^, 



as 

input 7r{vars^^^ ,v:T) ■where v = t A P^ 

Here, v:T is a fresh variable, that is, one that does not appear in vars , vars-^^, stateVars , 
postVars , localVars^^^,, or localPostVars ^^\, for any jr\ 

Let P^j^^j^ ^^ be the where predicate that results after all const parameters in pa^amSj^-^^ have 
been desugared. Let varsj,i^^ ^^ be the sequence of distinct variables that parameterize tt after 
desugaring. Note that all variables that occur freely in -Pj.j^')^ ^^ are either in vars^^l^^ ^^ or in 
vars"^. In general, vars^.^^^ ^^^ is a supersequence of varSf^^^^ (in that it contains a fresh variable 
for each const parameter in params f^l^^) . In the above example, a const parameter appears in 

'■^For the purposes of this transformation, it suffices to pick some v.T that does not appear in either vars or 
vars^^^ . However, by ensuring that v.T is distinct from additional variables, we avoid having to replace it by yet 



another fresh variable when we introduce canonical transition parameters, as described in Section [4. 2[ Furthermore, 
to avoid any ambiguity that may arise when two variables share an identifier, and to avoid having to replace v.T by 
yet another fresh variable in an instantiation of A that maps T and the sort of another variable with identifier u to a 
common sort, it is helpful to pick v to be an identifier that does not appear in vars , vars-^^ , stateVars , postVars , 
localVars^^^^., or localPostVars^,^^^. for any j. 
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automaton A{types , vars ) 
signature 



input TT{vars^;^^^^,^g) where P^„'^ A vars ^;^^^^,^g = params^^ 
output 7^{vars^;^l^^^^g) where P^^J A vars^;^^^^^^^^ = paramsj;^'^ 
internal T^ivarsf^^^^^^^^) where pf^; A varsf^^^^^^^^ = paramsf^^ 



states stateVars^ := initVals^ initially P^^^ 
transitions 



input T^ivarsf^^^^^^^^^g-, local /oca/ Vars f„';^, wars f„p case tj 
where P^:;^'J^ A farsf^'^^^^^^ = paramsf;^^^ 
efF Prog^j^^^, ensuring ensuring ■^^^, 
output vr(mrs;J;^. . ; local /oca/Fars;^;^^^ wars;^;^^. ) case t 



A.n . A,iT A,' 



where P^^l^^ A wars„;^j^,_^^,„^ = params^;^^^. 
pre Pre„;^ j^, 

efF Prog^^^^^ ensuring ensuring g;^^^^ 
internal T^ivarsf^l^^^^^^^g] local localVarsf^l^^,varsil^^^) case tj 

where Pf^^''^^^ A warsf„';^^^,^^^^„^ = paramsf^';^^^. 
pre ^re .„, ,^. 
efF Progf^l^^ ensuring ensuringf^^^^ 

Figure 4.1: Preliminary form of a desugared primitive automaton: all action parameters are vari- 
ables 
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the last position of params^^^ . In general, const parameters may appear in any position. A fresh 
variable appears in varSf.-^^^ desun ^^ ^^^ same position the const parameter it replaces appears in 

The preliminary form for desugaring an automaton signature shown in Figure |4.1| indicates 
that each variable in varSf.-^^ ^^ is equated to the corresponding entry in params f.-^^. (In the 

figure, we use paramsj^jl^^ to mean the sequence of terms without the const keyword.) An obvious 
simplification is to omit any identity conjuncts that arise when a variable in varSj^-^^^ is equated to 
itself. 

Transition definitions 

We desugar the parameters for each transition definition for an action named vr to eliminate pa- 



rameters that are not just simple variable references. As shown in Figure 4.1, we first replace 



A,^ 



the transition parameters params^-^^ ^, by references to distinct fresh variables varsj^-^^ j, (^g^„„, that 
is, to variables that do not appear in vars , stateVars , postVars , varsy^^ ^, , localVarsy^^ j, , or 

A,1T 



localPostVarSj^^^^^^ 
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adding conjuncts toT 



Second, we maintain the original semantics of the transition definition by 
re where clause to equate the new variables with the old parameters. Third, 
because transition definition parameters may introduce variables implicitly, but where clauses may 
not, we introduce the previously free variables (i.e., varsj^-^^ j) as additional local variables, letting 

localVars^l^^ ^, ^^ be the concatenation of localVars^l^^ ^, and varSf^l^^^,. In effect, these steps 
move terms used as parameters into the where clause. For example, if t is a term and v is a fresh 
variable with the same sort as t, then we desugar the transition definition 

input 7r(t) where P^:^J 

as 

input 7r(u; local vars^^\.) where v = t /\ -Pj„'^, 

Let Pj^j^^fi J, (if,su„ be the where predicate that results after transition parameters have been 
desugared in this fashion. Then any variable that has a free occurrence in this predicate must be 
in vars^, ^ars^^^^^^^^^^^^, or localVarsi^^^^^^^^^^. 

After const and transition definition terms have been desugared, the valid occurrences of free 



variables in syntactic forms, shown in Table 3.1, is revised by those shown in Table 4.1 After 
desugaring, params^;^^ = vars^l^^^^^^^^ and params^^^^^^^ = varsf^^^^^^^^^^^. 



Example 4.1 The first step in desugaring the primitive automata defined in Figures 2.1-2.3 is 



shown in Figure 4.2 For the automaton Channel, nl : Node and n2 : Node are fresh variables introduced 



to desugar the const parameters in the signature. Similarly, nl:Node, n2:Node, and ml:Msg are 



^"As mentioned in Footnote 111 we distinguish between action parameters in the signature that are terms (const 
parameters) and those that are variable declarations to provide strong typing for variable declarations. Since the sorts 
oi paramsj^l^^ determine the sorts oi params^l^^ j., there is no need for such a distinction in transition parameters. 

'^^It suffices to replace just those parameters that are not simply references to variables, because the fresh variables 
corresponding to such terms disappear when we substitute references to canonical variables for the parameters, as 
described in the next section. However, the replacement is easier to describe if we replace all parameters. 

Furthermore, as for const parameters, to avoid any ambiguity that may arise in the where clause when two 
variables share an identifier, and to avoid having to replace v.T by yet another fresh variable in an instantiation of 
A that maps T and the sort of another variable with identifier n to a common sort, it is helpful to pick v to be an 
identifier that is not in vars , stateVars , postVars , varSj.-^^^ j., localVars f.-'^^^ ^ , or localPostVarSi. 



kind,t^ 
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LOCATION OF TERM 


VARIABLES THAT CAN OCCUR FREELY IN TERM 


pA,-K 
kind,desug 


vars^, vars^l^^^^^^^g 


pA,n 

kind,tj,desug 


vars^, ««^s^»„"d,i,,des«g' ^ocalVars^^^^^^^^^^g 



Table 4.1: Variables that can occur freely in terms in the definition of a desugared primitive 
automaton. Variables listed on the right may occur freely in the syntactic structure listed to their 
left. 



fresh variables introduced to desugar transition parameters. Since both vars 



vars 



„ Channel, receive 

0Ut,t2 



ChcLnnel,send 



and 



contain the single variable m : Msg, we introduce m : Msg as a local variable for each 
transition definition. Notice that the variables introduced for each action need be fresh only with 
respect to i:Node, j:Node, and m:Msg; furthermore, "freshness" need not extend across transitions 
or between actions and transitions. 

The automata P and Watch are desugared in a similar fashion. Since there are no const parame- 
ters in the signature of Watch, that signature is unchanged. Since the parameters for the transition 
definitions for the overflow action in Watch contain two free variables, x and s, the desugared tran- 
sition definitions declare these variables as local. Also, in the second of the desugared transition 
definitions, the desugared where clause incorporates the original where clause as a conjunct. 



4.2 Introducing canonical names for parameters 



Signature 

lOA does not require that the sequences of variables vars 



A,1T 



A.TT J A,n 

vars^^t, and vars ^^^ 



be the same. For 

example, const parameters may cause these sequences to have different lengths. However, since lOA 
requires params^^^ ^ params^^, and params-^^ to contain the same number and sorts of elements, 
the desugared versions of these sequences (i.e., varsf^'^^^^^^, ^ars^uldesug^ and varsf^^^^^^g) do have 
the same number and sorts of elements. We choose one of these desugared variable sequences to 
be the canonical parameters for the action vr in A. We call the canonical sequence vars ''^ . We 
replace the other two sequences of parameters for vr in the signature of A by vars ''^, and we define 
substitutions crjj^^ to replace vars ''^ 



kind 



kind,desug 



with vars '"^ in -Pj.j^']^ 
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Transition definitions 

We canonicalize the parameters for each transition definition for an action named vr so that the 
definition also uses vars ''^ as its parameters. Specifically, we replace the references to variables 



that parameterize a desugared transition definition of vr (i.e., vars 



kind,tj,desug) 



by references to 



the canonical variables (i.e., vars ''^) throughout the transition definition. Therefore we define a 
to perform this replacement and apply it to the whole transition definition. 



substitution a 



kind , ti 



As described in Section^ if the canonical variables clash with the desugared local variables (i.e., 
iocalVars i^-^^ j. ^g^^,), we must substitute fresh local variables for those that clash. The variables 

introduced by the substitution must be be distinct and fresh with respect to vars , vars '"^ , and the 



^^See Sectionl9|for a precise definition of a substitution, wliicli maps a set of variables to a set of terms. Often we 
represent the domain and range of a substitution as sequences, with the ith variable in the domain being replaced by 
the jth variable or term in the range. 
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automaton Channel (Node , Msg:type, i, j:Node) 
signature 

input send(nl, n2 : Node , m:Msg) where nl = i A n2 = j 
output receiveCnl, n2 : Node , m:Msg) where nl = i A n2 = j 
states contents : Set [Msg] := {} 
transitions 

input send(nl, n2 , ml; local m:Msg) where nl = i A n2 = j A ml = m 

eff contents := insert(m, contents) 
output receiveCnl, n2 , ml; local m:Msg) 
where nl = i A n2 = j A ml = m 
pre m G contents 
eff contents := delete(m, contents) 

automaton P(n:Int) 
signature 

input receive (il, 12, x:Int) where il = n-1 A 12 = n 
output send(il, 12, x:Int) where 11 = n A 12 = n+1, 
overflow ( 11 : Int , s:Set[Int]) where 11 = n 
states 

val : Int := , 
toSend : Set [Int] := {} 
transitions 

input recelveCll, 12, 13; local x:Int) 
where 11 = n-1 A 12 = n A 13 = x 

eff ... 7o effect clause unchanged from original definition of P 

output send(il, 12, 13; local x:Int) 
where il=nAi2 = n + lA i3 = x 
pre X G toSend 

eff toSend := deleteCx, toSend) 
output overflowCil, si; local t, s:Set[Int]) where 11 = n A si = s 
pre s = toSend A n < size(s) A t C s 
eff toSend := t 

automaton Watch (T : type , what : Set [T] ) 
signature 

input overf low (x : T , s : Set [T] ) where x G what 
output found (x:T) where x G what 
states seen : Array [T , Bool ] := constant ( false ) 
transitions 

input overflowCtl, si; local x:T, s : Set [T] ) 
where tl = x A si = s U {x} 
eff seen[x] :~ true 
input overflowCtl, si; local x:T, s : Set [T] ) 
where ^(xGs) Atl = xAsl = s 
eff seen [x] :— false 
output foundCtl; local x:T) where tl = x 
pre seen [x] 

Figure 4.2: Preliminary desugarings of the sample automata Channel, P, and Watch 
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automaton A{types , vars ) 
signature 



input nivars'^''') where (rfn'' (Pfn^desug) 
output TT{vars^''') where a^uUPout,desug) 
internal TT{vars'^''') where cytt {Ptnt,desug) 



states stateVars^ := initVals initially P^^^ 



transitions 



A,n 



Oi. 



a 



_A,TT 



input TT{varsf;l^^^^^^; local localVarsf^^^^ ^^^^^g) case tj where P^^J 



in,tj,desug^ 

eff Prog-^^f., ensuring ensuring j^^^^.. 



output TT^varSg 



ut,tj,desug^ 



local localVars 



out,tj,desug 



) case tj where P 



out,tj,desug 



pre Pre 



OUt^tj 
A,1T 



efF Prog^'^^ ^, ensuring ensuring 



A,-K 
OUt,tj 



A,n 



internal Tr(vars 
pre Pre,^. 



A,TT 

int,tj,desug' 



local localVars 



int ,tj ,desug ■ 



case tj where P'- 



A,T! 



int , tj ,desug 



efF Prog ■ '7, ensuring 



ensuringf^^. 



Figure 4.3: Intermediate form of a desugared primitive automaton with canonical action parameters 



(cf. Figure 4.1) 



desugared local variables. The substitutions for canonicalization are listed in Table 4.2 Variables 
listed in the center column are mapped by the substitution named in the left column to those listed 
in the right column. 



Simplifying local variables 

Finally, we simplify each desugared and canonicalized transition definition for actions named vr by 
eliminating extraneous local variables. A local variable may be eliminated if it is never an lvalue in 
an assignment in the transition definition for vr and if the where clause equates it with a canonical 
variable for vr, that is, if it is used only as a constant in the transition definition and is already 
named by a canonical parameter. 

This simplification is accomplished in four steps. 



1. Define a substitution cr^^^^ j. ^- that maps the redundant local variables to the corresponding 
canonical variables. 



2. Apply cj^.;"^,^,_^.^p to each 
clauses. 



clause in the transition definition: the where, pre, efF, and ensuring 
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SUBSTITUTION 


DOMAIN 


RANGE 


A,7r 
"kind 


'"^''"^kind,desug 


vars^'^ 


A,-K 

kind,tj 


A,TT 

vars , ■ J , J 

kmd,tj,desug 


vars^''' 


A,n 

kind, tj, simp 


Redundant variables in <rfi:^d,t,i^ocalVarsf.;^^^^^^^^^g) 


vars^'^ 


a^ 


X e stateVars^ 


A:States[A, types'^].x 


x' G postVars 


A':States[A, types^].x 


X E localVarsli;^^^^ 


A:Locals[A, types^, vrj.x 


x' G localPostVars^l^j^^, 


A':Locals[A, types'^, vrj.x 



Table 4.2: Substitutions used in desugaring a primitive automaton. Substitutions listed on the left 
map variables in the domain to their right to variables in the range their far right. 



3. Delete identity conjuncts from the where clause. 

4. Delete the declarations of local variables that no longer appear in the transition. 



Example 4.2 The second step in desugaring the primitive automata defined in Figures 2.1-2.3 is 



shown in Figure 4.4 The definitions in this figure are obtained from those in Figure 4.2 by selecting 
canonical parameters for each action. 

Since each action occurs only once in the signature of the automaton Channel, selecting the 
canonical variables is trivial: 



vars 



Channel.send defaults to vars^^^^^^f'^^''^ = (nl:Node, n2:Node, m:Msg), and 

(nl:Node, n2:Node, m:Msg). 



^^^^gChannel.receive defaults to vars 



in,desug 

Chcinnel, receive 



out,desug 



These selections also make canonicalizing the signature trivial, because identity substitutions suffice. 
We canonicalize the transition definitions by defining two substitutions. 



Channel, send Channel, send / ^ ,, , „ ., , ^ ., \ j. 

cr,„ t. maps vars-^j^^^^^^; = (nl:Node, n2:Node, ml:Msg), to vars 



ChcLnnel,send 



in,ti ''^'■"■f^ ''"■'•^in,ti,desug — \xix . .,w^^, ^x^ . i,v.^=, m.. .,,05/, uw ^.u,, o by 

replacing the parameter ml : Msg with the canonical parameter m : Msg. To avoid a conflict 
between the local variable m:Msg and the canonical parameter m:Msg, the substitution also 
replaces m : Msg by the fresh variable m2 : Msg. 

T ,1 Channel, receive Chamnel, receive / ^ „ , ^ „ -, ^ .. \ 

In the same way, (Tg^^^^^ maps vars^^^^^^^^^'^^ = (nl:Node, n2:Node, ml: Msg) 



to vars 



Channel, receive 



by replacing the parameter ml : Msg with the canonical parameter m : Msg 



and the local variable m:Msg with the fresh variable m2:Msg. 

Applying these substitution to the transition definitions produces 

input sendCnl, n2 , m; local m2:Msg) where nl = i A n2 

eff contents := insert(m2, contents) 
output receive (nl , n2 , m; local m2:Msg) where nl = i A n2 
pre m2 € contents 
eff contents := delete(m2, contents) 



j A m = m2 

j A m = m2 
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automaton Channel (Mode , Msg:type, i, j:Node) 
signature 

input send(nl, n2 : Node , m:Msg) where nl = i A n2 = j 
output receive (nl, n2 : Node , m:Msg) where nl = i A n2 = j 
states contents : Set [Msg] :— {} 
transitions 

input send(nl, n2 , m) where nl = i A n2 = j 

eff contents := insert (m, contents) 
output receive (nl, n2 , m) where nl = i A n2 = j 
pre m G contents 
eff contents := delete(m, contents) 

automaton P(n:Int) 
signature 

input receive (il, 12, x:Int) where il = n-1 A 12 = n 
output send (11, 12, x:Int) where 11 = n A 12 = n + 1, 
overflow ( 11 : Int , s:Set[Int]) where 11 = n 
states 

val : Int := , 
toSend : Set [Int] := {} 
transitions 

input receive (11, 12, x) where 11 = n-1 A 12 = n 
eff if val = then val := x 
elseif X < val then 

toSend := Insert (val, toSend); 
val := X 
elseif val < x then 

toSend := lnsert(x, toSend) 
fi 
output send (11, 12, x) where 11 = n A 12 = n + 1 
pre X e toSend 

eff toSend := delete(x, toSend) 
output overflowdl, s; local t:Set[Int]) where 11 = n 
pre s = toSend A n < slze(s) A t C s 
eff toSend := t 

automaton Watch (T : type , what : Set [T] ) 
signature 

input overf low (x : T , s : Set [T] ) where x G what 
output found (x:T) where x G what 
states seen : Array [T , Bool ] := constant ( false ) 
transitions 

input overflow(x, s; local s2:Set[T]) where s = s2 U {x} 

eff seen[x] := true 
input overflow(x, s) where ^(x G s) 

eff seen[x] := false 
output found (x) 
pre seen [x] 

Figure 4.4: Intermediate desugarings of the sample automata Channel, P, and Watch, obtained from 
the preliminary desugarings in Figure |4.2| by selecting canonical parameters for each action 
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However, the local variable m2 is extraneous in both transition definitions, because it is equated with 
m in the where clause and no value is assigned to it. Hence m2 equals m throughout the transition, 
and we can eliminate it entirely by applying a substitution (e.g., a^^ ^^ ^^ ' , which maps m2 to 
m) to the where, efF and pre (in the case of receive) clauses and simplifying the result, as shown in 



Figure 4.4 



As for Channel, each action occurs only once in the signature of the automaton P. Hence, it is 
trivial to select vars '^^'''^'''^^, vars '^^ , and vars '°^^^ ^^ and to canonicalize the signature. 

rp P, receive /■ / ■ ^ -r ^ ■ r, -r ^ •oT...\\i P receive j n P, receive 

To map vars^^^^j^^^^g (i.e., (il:Int, i2:Int, i3:Int)) to vars'"''-^^^-^^^ , we dehne cr^^^^^ 

to replace i3:Int by x:Int. To avoid conflicts between the local variable x:Int and the canonical 

parameter x:Int, the substitution also replaces x:Int by i4:Int. Applying this substitution to the 

transition definition produces: 

input receiveCil, i2 , x; local i4:Int) where il ~ n-1 A i2 = n A x = i4 

eff if val = then val := i4 

elseif i4 < val then 

toSend :— insert(val, toSend); 

val := 14 

elseif val < 14 then 

toSend := insert(i4, toSend) 

fi 

Since the local variable 14 equals x throughout the transition definition, we can eliminate it entirely 
by defining a substitution mapping 14 to x, applying that substitution to the where and eff clauses, 
and simplifying the result, as shown in Figure [474} 

Canonicalization of the send transition follows the same pattern as the receive transition. 
Application of the canonicalizing substitution a^'^i ^^ yields: 

output send(ll, 12, x; local 14 : Int ) where 11 = n A 12 = n+1 A x = 14 

pre 14 e toSend 

eff toSend := delete(14, toSend) 



This definition simplifies to the one shown in Figure 4.2 which does not contain a local variable. 
Similarly applying the canonicalizing substitution 0"^^^ ^ to the overflow transition yields: 

output overflowCll, s; local t, s2:Set[Int]) where 11 = n A s = s2 
pre s2 = toSend A n < slze(s2) A t C s2 
eff toSend := t 



Once again, this definition simplifies to the one shown in Figure 4.2 Notice that the local variable 
t cannot be eliminated because it is not equated with a canonical parameter. Further notice that, 
in this case, canonicalization has eliminated all the local variables introduced in the desugaring 
step. 

As for Channel and P, each action occurs only once in the signature of the automaton Watch. 
Hence it is trivial to select ^areW^*=^'°^^^f 1°" and ^0^^^*=^'^°™'^. 

Canonicalizing the two transition definitions for overflow proceeds by defining a^^ ^ 

and a^^ ^^ ' , which happen to be the same. They map tl:T to x:T, sl:Set[T] to s:Set[T], 

s:Set[T] to s2:Set[T], and x:T to t2:T. Applying these substitutions to the transition definitions 
yields: 

input overflowCx, s; local t2:T, s2 : Set [T] ) 
where x = t2 A s = s2 U {t2} 
eff seen[t2] :— true 
input overflowCx, s; local t2:T, s2:Set[T]) 
where ^(t2 e s2) A x = t2 A s = s2 
eff seen[x] := false 
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The local variable t2:T can be eliminated from both transition definitions. The local variable 
s2:Set[T] can be eliminated from the second transition definition but not from the first. These 



simplifications result in the transition definitions shown in Figure 4.4 



Notice that after the simplification of the local variable, the semantic meaning of the parameter 



s : Set [T] in the desugared and canonicalized automaton shown in Figure 4.4 is different than the 



meaning of the parameter s:Set [T] in the original automaton shown in Figure 2.3 The parameter 



s : Set [T] in the original actually corresponds to the local variable s2 : Set [T] in the canonicalized 
version. 

Applying the canonicalizing substitution a^^ ^ ' to the found transition yields: 

output found (x; local t2:T) where x = t2 
pre seen [t2] 



After its local variables are simplified, the transition definition shown in Figure 4.4 is identical to 



the one originally defined in Figure 2.3 



4.3 Combining transition definitions 



We will see in Sections 7.7-7.9 that combining multiple transition definitions for a given action into 
a single transition definition is useful for composing automata. It is necessary for combining input 
actions that execute atomically in the composition, and it avoids a code explosion multiplicative in 
the number of input and output actions. Because this transition combining step is easy to under- 
stand when applied to a single primitive automaton, we describe it here and assume all automata 
hereafter have only a single transition definition per kind per action, as shown in Figure 4.5 To 



combine the transition definitions for a given kind of an action vr, we need to combine their se- 
quences of parameters, their local variables, and their where, pre, efF, and ensuring clauses into 
one, semantically equivalent, transition definition. 

Furthermore, as will be discussed further in Section [7j the kind of an action may be changed 
by composition. Input actions may be subsumed by output actions, and output actions may be 
hidden as internal actions. Thus, the expansion of a composite automaton may combine transition 
definitions across kinds. To facilitate such combinations, we collect together all the local variables 
for each action of an automaton A into a single sequence of variables localVars '^, which is the 
concatenation (with duplicates removed) of the all sequences localVars j^-^^ j,. Again, this variable 
combining step is easy to understand when applied to a single primitive automaton, so we describe 
it here and assume all automata hereafter have only one sequence of local variables per action 
name. 

In describing this combination, we assume that parameters of the automaton have already 



been desugared and canonicalized as described in Sections 4.1 and 4.2, In Figure 4.5 and the 
discussion below, we indicate the syntactic forms that result from that desugaring by use of the 



desug subscript. We rely on the key semantic condition (mentioned in Section 3.4 and discussed 



in Section 4.6) that exactly one transition definition be defined for each assignment of values to 

That is, within an automaton, all like-named transition definitions 



vars 



^''^ that satisfies P 



kind' 



must have where clauses that are satisfiable only for disjoint sets of parameter values. 



13 



First, notice that since all the contributing transition definitions are already desugared and 
canonicalized, each is is parameterized by vars '^. Hence, combining the parameters is trivial. 

At first glance, combining local variables looks trickier. Each transition definition has local 
scope with respect to local variables. So, there may be any amount of duplication of variables 



^^These semantic conditions also ensure that, in the absence of local variables, the resulting where clause can be 
eliminated because it will be equivalent to true. 
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automaton A{types , vars ) 

states stateVars := initVals initially cr^iP^a) 
transitions 

input TT^vars^'^; local localVars ''^) where \/ ■ P^^fl. ^^g^„ 



efF 



" ^in,tj,desug then -TTO^m'^i^.^desug 

elseif . . . 
fi 

-lA.TT , • A,- 



ensuring A^- [P ^n"t, ,desug ^ ('^^^''^^9^Z,,desug 

output -K^vars"^'^; local localVars ''^) where V,- -P, 



A,-K 
' j ^ OUt,tj 

'j \^ out,tj,desug '^ '' ' ^ out,tj,desug 

eff 



pre V, (^o1:tfc.de.«o ^ P^4ut 



" ^out,tj,desug ^hen -rro(/^^^ ^^^^^^^^ 

elseif . . . 

fi 

ensuring A^- (^o1;M^.,de.«3 ^ enstirm^;^^^^,^^^^^^ 



lA,TT 



internal 7r(uars ''^; local localVars ''^) ■where \/ ■ P^^^ ^ desua 
Analogous to output. 



Figure 4.5: Intermediate form of a desugared primitive automaton, with canonical action parame- 
ters and with all transition definitions for each kind of an action combined into a single transition 
definition 
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automaton Watch (T : type , what : Set [T] ) 
signature 

input overf low (x : T , s : Set [T] ) where x G what 
output found (x:T) where x G what 
states seen : Array [T , Bool ] := constant ( false ) 
transitions 

input overflowCx, s; local s2:Set[T]) where s = s2 U {x} V ^(x £ s) 
eff if s = s2 U {x} then seen[x] := true 
elseif ^(x e s) then seen[x] :— false 
fi 
output found (x) 
pre seen [x] 

Figure 4.6: Improved intermediate desugaring of the sample automaton Watch, obtained from the 



intermediate desugaring in Figure 4.4 by combining the transition definitions for overflow 



among the sequences localVars f.-^^ ^, ^g^„„. One might think that a correctly combined transition 
definition might need distinct local variables to store the values of the duplicate local variable appro- 
priate to each contributing transition definition. However, for each assignment of values to vars '"^ 
only one contributing transition definition can be defined for any assignment of values to its local 
variables. Therefore, there is at most one "useful" initial value for each local variable. Similarly, 
at most one contributing eff clause can make assignments to its local variables. Hence, duplicate 
declarations of local variables have no effect on the combined transition definition. Accordingly, we 
define localVars ''^ to be the sequence of variables obtained by removing any duplicates from the 
concatenation of all sequences localVars f,-^^ ^, (^g^„„- 

In combining the various clauses of the contributing transitions, we use the where clauses of 
the contributing transitions as guards to select the correct case to use. The four clauses of the 
combined transition are combined as follows: 

• The combined where clause is the disjunction of the where clauses from all the contributing 
transition definitions. 

• For output and internal transition definitions, the combined pre clause checks that one set of 
parameters fulfills both the where and pre clauses of some contributing transition definition. 

• The combined eff clause is a single if. . .then. . .elseif. . .fi statement in which the contribut- 
ing eff clause is guarded by the associated where clause. 

• Similarly, the combined ensuring clause asserts the appropriate contributing ensuring clause 
when the associated where clause is true. Note that since -P^j^')^ j, j^^sua ^^ defined on the initial 

values of localVars f.-^^ ^, ^g^^^, assignments made to local variables in the eff clause have no 
effect on which ensuring clause is asserted. 



Example 4.3 Consider the desugared and canonicalized automaton Watch shown in Figure 4.4 



The only action with multiple transition definitions is the overflow input action. Following the 



above recipe, they are combined into the one equivalent action shown in Figure 4.6 



4.4 Combining aggregate sorts and expanding variable references 

Section [3 . 2| described aggregate sorts that are automatically defined for the state and local variables 
of an automaton A (i.e., States[A, types ] and Locals[A, types , kind, 7r,tj]). Desugaring alters the 
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automaton A{types , vars^ 



states stateVars := initVals initially a^{P^^i) 
transitions 

kind TT^vars^''^; local localVars ''^) where P/.^'^^ 



a 



a 



kind 



kind, comb, ti 



A,n 



pre Pre,^^^^ 

efF Prog^;^^ ensuring ensuring^^^^ 



Figure 4.7: Final form of a desugared primitive automaton, with canonical action parameters, with 
all transition definitions for each kind of an action combined into a single transition definition, and 
with all variable references expanded. 



automaton A and, consequently, can alter these aggregate sorts. In particular, as discussed in 



Section 4.3 combining multiple transition definitions for a particular action vr in automaton A 
involves combining the local variables that appear in each transition into a single sequence. We 
collect together all the local variables for each action vr of an automaton A into a single sequence 
of variables localVars ''^, which is the concatenation (with duplicates removed) of the all sequences 
localVars^^^^^^. 

As a result, the aggregate sort for local variables also changes. Notationally, the kind and case 
labels tj are dropped from the aggregate local sort name Locals[A, types , kind,7r, tj]. We define a 
new sort Locals[A, types , n] for the combined transition definition to be a tuple with selection oper- 
ators that are named, typed, and have values in accordance with the local variables in localVars '^. 
That is, the set of identifiers for the selection operators on the sort Locals[A, types , tt] is the union 
of the sets of identifiers for the selection operators on the sorts Locals[A,types ,kind,7r,tj]. We 
change the sorts of the aggregate local and post-local variables A and A' to this new sort. This has 
the effect of collapsing multiple aggregate local and post-local variables each defined in the scope 
of one transition into a single local and post-local variable defined in all transitions for a given 
action p^. 

Formally, for each transition definition tj for a given kind of an action vr in A, we define a 
resortina^that maps the aggregate local sort Locals[A, types , kind, vr, tj] to the new aggregate local 
sort Locals[A, types ,7r], and we apply that resorting to the transition definition before performing 
the combining step. As a result, each variable A:Locals[A, types , kind^-K, tj] is mapped to a variable 
A:Locals[A,types jir]. Thus, local variable references using the notation A.v form remain well 
defined and the resorting does not change the text of the transition definition. After combining, 
the sorts Locals[A, types , kind, vr, tj] may be ignored. 



In addition to introducing notations for aggregate local sorts. Section 3.2 also introduced no- 
tations for aggregate state sorts. These notations provided an additional, and potentially less 
ambiguous, way of referencing the values of local and state variables. We now desugar simple 
references to local and state variables to use the notations for aggregate local and state variables. 



^''To avoid complications that arise when new fields are added to an aggregate local tuple during the combining of 
local variables across transitions, we should disallow use of the constructor [ , . . . ] for aggregate local sorts. 



^^See Section 9 for a formal definition of resortings, which map sorts to sorts. 
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Formally, we define a substitutioEpj o" to map state and post-state variables to terms. If j; is a 
state variable or a post-state variable (i.e., x G stateVars or a; G postVars ), then a {x)) = A.x, 

where A has sort States[A, types ] and the operator .x has signature States[A, types ] — > T, 

where T is the sort of x. 

Similarly, for each transition definition vr of type kind, we define a substitution o"^^^^ to map 
local and post-local variables to terms. If 2; is a local or post-local variable (i.e., x £ localVars ''^ 
or x G localPostVars ^.^^^) , then o-j^^^{x) = A.x, where A has sort Locals[A, types^, kind,7r], and the 
operator .x has signature Locals[A, types , kind,TT] — > T, where T is the sort of x. 



Figure 4.7 shows the final form of a desugared primitive automaton with canonical action 
parameters and local variables and with all transition definitions for each kind of an action combined 
into a single transition definition, and with all variable references expanded. In that figure, we 
indicate the syntactic forms that result from the combining step by use of the comb subscript. 



Figure 4.8 shows the result of applying these substitutions to the sample primitive automata. 



4.5 Restrictions on the form of desugared automaton definitions 



After the definition of a primitive automaton A has been desugared as described in Sections 4.1-4.4 
it has the following properties. 

• No const parameters appear in the signature of A. 

• Each appearance of an action vr in the signature of A is parameterized by the canonical action 
parameters vars ''^ of vr in A. 

• Each transition definition of an action vr is parameterized by the canonical action parameters 
vars '^ of vr in A; i.e., every parameter is a simple reference to a variable in vars ''^. 

• Each action name has at most one transition definition of each kind. 

• Each reference to a state variable x of A, other than in the list of state variables in the states 
statement, has been replaced by the term A.x. 

• Each reference to a post-state variable x' of A has been replaced by the term A' .x. 

• Each reference to a local variable x in a transition of A, other than in the local clause of that 
transition definition, has been replaced by the term A.x. 

• Each reference to a post-local variable x' in a transition of A has been replaced by the term 
A'.x. 

4.6 Semantic proof obligations, revisited 

We are now ready to formalize the semantic proof obligations for primitive automata introduced 



in Section 3.4 Previously, we said that for each action named tt and each sequence of parameters 
values: 

1. At most one of P^^^ , Pout 1 ^^"^ ^int^ is true. 

2- If P^nd is true, at least one P^^^^^^ is true. 

^^See Section 9 for a formal definition of substitutions, which map variables to terms. 
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automaton Channel (Node , Msg:type, i, j:Node) 
signature 

input send(nl, n2 : Node , m:Msg) where nl = i A n2 = j 
output receive (nl, n2 : Node , m:Msg) where nl = i A n2 = j 
states contents : Set [Msg] := {} 
transitions 

input send(nl, n2 , m) where nl = i A n2 = j 

eff Channel . content s := insert (m, Channel . content s ) 
output receive (nl, n2 , m) where nl = i A n2 = j 
pre m G Channel . content s 
eff Channel . content s := delete (m, Channel . content s ) 

automaton P(n:lnt) 
signature 

input receive (il, 12, x:lnt) where il = n-1 A 12 = n 
output send (11, 12, x:lnt) where 11 = n A 12 = n+1, 
overflow ( il : Int , s:Set[lnt]) where il = n 
states 

val : Int :— , 
toSend : Set [Int] := {} 
transitions 

input receive (11, 12, x) where il = n-1 A 12 = n 
eff if P. val = then P . val := x 
elseif X < P . val then 

P.toSend := insert (P . val , P.toSend); 
P . val :— X 
elseif P . val < x then 

P.toSend := insert(x, P.toSend) 
fi 
output send (11, 12, x) where il = n A 12 = n + 1 
pre X e P . toSend 

eff P.toSend := delete(x, P.toSend) 
output overflowdl, s; local t:Set[lnt]) where il = n 
pre s = P.toSend A n < size(s) A P.t C s 
eff P . toSend := P . t 

automaton Watch (T : type , what : Set [T] ) 
signature 

input overf low (x : T , s : Set [T] ) where x G what 
output found (x:T) where x G what 
states seen : Array [T , Bool ] := constant ( false ) 
transitions 

input overflow(x, s; local s2:Set[T]) 

where s = Watch. s2 U {x} V ^(x G s) 
eff 

if s = Watch. s2 U {x} then Wat ch . seen [x] := true 
elseif ^(x G s) then Watch . seen [x] := false 
fi 
output found (x) 

pre Watch . seen [x] 

Figure 4.8: Sample desugared automata Channel, P, and Watch, obtained from the intermediate 



desugarings in Figures 4.4 and 4.6 by desugaring references to state and local variables 



29 



3- If Pi^nd is true, at most one P^,^^ is true 



We explicitly did not define the phrase "sequence of parameters values" because these predicates 
may be stated in terms of different variables. In other words, vars^^ may be different from vars^^ 
and vars^^\^ . Similarly, vars^^\^ may be different from vars^^\ . However, after desugaring and 
canonicalizing (but before combining) , we have predicates that are semantically equivalent to those 
in the original automaton, but defined over a common set of free variables. That is, all the free 
variables of all the predicates (rt^ndiPkind,desug) and cj^'nd,t,iPkind,t,,desug) are among vars^ and 
vars '^ . 



The alert reader will realize that Tables 



3.1 



and 



4.1 



list localVars 1^-^^ j, among the variables that 



may occur freely in Pj^^!^^ ^. and -Pj.j^'^ j, ^g^^, and might therefore conclude that the aforementioned 



predicates are not "defined over a common set of free variables". However, as noted Section 3.2 
transition it is defined only for values of its parameters that, together with some choice of initial 
values for its local variables, satisfy the where clause of the transition definition. Thus, for the 
purposes of formalizing the semantic proof obligations for transition definitions, local variables 

jA,TT 

kind,tj,desug 



should be existentially bound, not free in where clauses, that is, -Pi,,''!j f. j„„,,. should be preceded 



by ^localVarsf^^^^^^. 

The semantic proof obligations we introduced in Section 3.4 can be stated precisely as follows. 
We require that for each action name vr, all values of vars , and all values of vars '"^j the following 
statements must be provable from the axioms provided by lOA's built-in types, by the theories 
associated with the type definitions and the axioms in the lOA specification that contains the 
automaton definition, and by the theories associated with the assumes clause of that definition. 

^ ~^ y^in \Pm,desug) ^'^out\Pout,desug)) ^ V^-^) 

^ "■ y^in \Pin,desug) ^ ^int \P int ,desug) ) ' (4-2) 

^ ^ yout{Pou't,desug) ^ ^ int iP inldesug)) ' (4-3) 

^ '^kindiPk^nd4esug)^\|^^ocalVarsli^^^a^l^^^^{P^^^^^^ and (4.4) 

j 

'•' ^kind\Pkind,desug) ^ V^-^) 



when j ^ k. 



A,TT N 

kind,ti^,desug' 
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5 Definitions for composite automata 



This section introduces notations and semantic checks for composite lOA automata. Section 5.1 



describes the syntactic structures that may appear in an lOA description of a composite I/O 



automaton. Section 5.2 describes notations for the state variables of a composite automaton. 
When component automata have type parameters, the sorts of these state variables are obtained 
by mapping the formal type parameters of the component automata to the actual parameters used 
to instantiate those components in the composition. Finally, Sections |5.3| and |5.4| describe the 
conditions that descriptions of composite automata must satisfy to be semantically valid. 

5.1 Syntax 

As for primitive automata, we introduce a labeling of the syntactic elements of composite lOA 



programs in order to facilitate describing their syntactic manipulation. Figure 5.1 indicates a 
particular labeling of the expressions that can appear in the 10 A definition of a composite I/O 
automaton. Again, we have selected the granularity of this labeling to expose just those elements 
of composite lOA programs that are needed in Section [7] to describe the expansion of composite 
automata into primitive form. 

automaton D{types , vars ) 
assumes Assumptions 
components 

Ci[vars^''^'] : Ai{actualTypes^''^' , actuals^'^') where P^'^i-, 
. . . , 

Cn[vars^''^"] : An{actualTypes^''^'\ actuals ^''^'') where P^''^" 
hidden 

Tri{params^^l[) where iJ^^^^^^ ; 

TT.m{params^.'ll) where H^^f^^ 

invariant of D : Inv ^ ; . . . Inv^ 

Figure 5.1: General form of a composite automaton 



In Figure 5.1 parameterized components named Ci, . . . , Cn are based on instantiations of au- 
tomata named Ai,...,An. The formal parameters of component Ci are vars^'^% and the ac- 
tual parameters of automaton Ai consist of a sequence actualTypes ' ' of sorts and a sequence 
actuals ' ' of terms. lOA permits the specification of Cj to be abbreviated by deleting the colon 
and the following expression when d and Ai are named by the same identifier, actualTypes 



D,c, 



is empty, and actuals ' ° = vars^''^'- (e.g., see component P in Example 2.4). In the specification 



D, 



of hidden actions, paramSf^^^^ is a sequence of terms, analogous to params ^^/^ , and we define 

)CC 

invariant of D is stated as a predicate Inv^ . 



varSf^-'^J to be the set of variables that occur freely in paramSf^-^J but are not in vars^ . Each 
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SYNTACTIC STRUCTURE 


FREE VARIABLES 


actuals^'^' 


vars , vars ' '^ 


pD,a 


vars^ , vars^''-^'- 


ttD,-Kp 

hidcp 


D D,TT„ 


params^^ll 




Inv^ 


vars^ , stateVars^ 



Table 5.1: Variables that can occur freely in terms in the definition of a composite automaton. 
Variables listed on the right may occur freely in the syntactic structure listed to their left. 



Example |2.4| conforms to this general form, as follows. 

• The first component of Sys is named C. Its parameters, vars '^^' , are (n: Int), and it is based 
on the automaton Channel, for which it supplies the actual parameters actualTypes ^^' = 
(int, Int) and actuals ^^' = (n, n+l). 

• The second component of Sys is named P. It has the same parameters as C. By the conventions 
for abbreviating component descriptions, it is based on the automaton of the same name, for 
which it supplies the actual parameters actuals ^^' = (n); in this case, actualTypes ^^' is 
empty (as required to use this abbreviated form). 

• The third component of Sys, named W, has no parameters. It is based on the automaton Watch, 
for which it supplies the actual parameters actualTypes ^^' = (int) and actuals ^^' = 
(betweenCl ,nProcesses)). 

• The send actions that Sys inherits from P[nProcesses] are hidden as internal actions in Sys. 
The parameters params^^^^' = (nProcesses,nProcesses+l,m) in the single clause in the 

hidden statement involve a single free variable in vo-fSfJ^^' = (m:Int), and -ff^j^g ' is 

true. 



The predicate 

V m: Int V n: Int (1 < 

is invariant Inv -j^ of Sys. 



A m < n A n < nProcesses 
> P [m] . val < P [n] . val V P [n] . val 



= 0) 



5.2 State variables of composite automata 

The definition of a composite automaton in lOA does not mention the automaton's state variables 
explicitly. Rather, its components statement implicitly introduces a single state variable for each 
component. We first describe the notations lOA provides for state variables associated with com- 
ponent automata that have no type parameters. Then we describe how these notations extend to 
state variables associated with component automata that have type parameters. Our goal is to 
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provide a precise explanation of notations for state variables such as P[m] .val, which appears in 
the invariant for the sample composite automaton Sys. 



As for primitive automata (see Section 3.2), we automatically define a sort States[D , types ] 
representing the aggregate states of a composite automaton D, and we also define aggregate state 
and post-state variables D and D' of sort States[D, types ]. Furthermore, we treat the sort 
States[D, types ] in the same fashion as for primitive automata, namely, as a tuple of state vari- 
ables: we define the aggregate state of a composite automaton D to be a tuple containing a state 
variable for each component automaton, and we use the names of the components (i.e., Ci, . . . , Cn) 

as the names of these state variables and of the corresponding selectors (i.e., .Ci, . . . , .Cn) of 

States[D, types^]. 

State variables for components ^vith no type parameters 

Defining the sort of the state variable Ci is simplest when the component Ci does not have pa- 
rameters and when the automaton Ai on which Ci is based does not have type parameters. For 

each such component Cj, the state variable Ci of D has sort States[Ai], and the selector .d has 

signature States[D ,types^] -^ States[Ai]. 

When the component Cj has parameters, but Ai still does not have type parameters, the 
situation is slightly more complicated, because the composite automaton D may contain multiple 
instances of Ai. For example, the composite automaton Sys contains nProcesses instances of the 
component automaton P, each with its own state variables val and toSend. These instances are 
parameterized by a single integer n and are distinguished by the component names P[l], ..., 
P [nProcesses] . 

For each parameterized component Cj, the corresponding state variable Ci does not refer to 
the aggregate state of a single instance of A^. Rather, it refers to a map from the values of the 
parameters vars^'^* of Ci to the aggregate states of A^. That is, the state variable Ci has sort 
n&Tpltypes ' ' , States[Ai]'i , where types '^ is the sequence of sorts of the variables in vars ' \ The 
selection operator .Ci has signature States[D,types^] —>■ Kajpltypes^''-^'- , States[Ai]'] . 

For example, the state variable P of Sys has sort Map [Int , States [P] ] . Hence, P [n] is a legitimate 

term with sort States [P] , and the term P [n] .val has sort Int. Likewise, the selection operator .P 

has signature States [Sys] -^ Map [Int, States [P]] , and Sys.P[n] .val is an alternative notation for 
the state variable val that Sys inherits from component P [n] . 

Resortings for automata w^ith type parameters 

Defining the sort of the state variable Ci is more complicated when Ai has type parameters. Since 
the semantics for lOA are defined using multisorted, first-order logic, we cannot quantify over sorts 
or use sorts as component indices. Instead, different instances of Ai, corresponding to different 
actual types, must be described in separate clauses in the components statement, where they 
are further distinguished by different component names. As a result, there can be only finitely 
many differently typed instantiations of Ai, even though altogether there may be infinitely many 
instances of Ai that are distinguished by the values of their non-type parameters. For example, 
a composite automaton might contain channel components that transmit finitely many different 
types of messages, but there may be infinitely many instances of such a component that transmits 
a given type of message. 

When a component Ci is based on an automaton Ai parameterized by the sorts types \ we 
define a resorting pi (which we write as p^^ in contexts, such as p , where it is more convenient to 
use the name of the component rather than its position in the list of all components) that maps 
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types "■ to actualTypes ' '. For example, p maps types ^^ = (t) to actualTypes ^^' = (int), 
and p^ maps types'^^^^^^'^ = (Node, Msg) to actualTypes^^^ '^ = (int, Int). 

As described in Section [9j there is a natural way to extend the resorting pi to map arbitrary sorts 
involving the formal type parameters in the defining automaton Ai to sorts involving the correspond- 
ing actual types that the component Ci supplies for A^. For example, this extension maps the auto- 
matically defined sort States[Ai, types^^] for the state of Ai to the sort States[Ai, actualTypes ' '] 
for the state of the instances of Ai corresponding to the component Cjj^ 

The resorting pi also extends naturally to map operators with signatures involving the formal 
type parameters in the defining automaton Ai to operators with signatures involving the corre- 
sponding actual types that the component Ci supplies for Ai. Thus, for example, p*^ maps 
States [Channel , Node , Msg] = tuple of contents: Set [Msg] 

to 

States [Channel , Int , Int ] — tuple of contents: Set [Int] 

and it maps the signature of the selection operator .contents from States [Channel, Node, Msg] -^ 

Set [Msg] to States [Channel, Int, Int] ^ Set [Int] . 

State variables for components ^vith type parameters 

When Ai has type parameters, we employ a resorting of its aggregate state sort to define the 
sort of the state variable Ci of D. In the simple case when the component Ci does not have any 
parameters, the state variable Ci has sort States[Ai, actualTypes ' '], and the selection operator 
.Ci has signature States[D, types ^] —>■ States[Ai, actualTypes ' ']. 

For example, the state variable W of Sys has sort States [Watch, Int] , the term W.seen has sort 

Array [Int, Bool], the selection operator .W has signature States [Sys] — > States [Watch, Int] , 

and Sys. Watch. seen is an alternative notation for the state variable seen that Sys inherits from 
component W. 

In the case when the component Ci has parameters (and the automaton Ai has type parame- 
ters), the state variable Ci has sort Ka.pltypes ' '- , States[Ai, actualTypes ' ']], where types '' is 

the sequence of sorts of the variables in vars^'^\ and the selection operator .Ci has signature 

States[D, types^] -^ Ha.-pltypes^''^' , States[Ai, actualTypes^''^']! . 

For example, the state variable C of Sys has sort Map [Int, States [Channel, Int, Int]], the term 
C[n] has sort States [Channel [Int, Int], the term C[n] . contents has sort Set [Int] , the selection 

operator .C has signature States [Sys] -^ Map[Int,States [Channel, Int, Int] , and C[n] .contents 

is an alternative notation for the state variable contents that Sys inherits from component C[n]. 

5.3 Static semantic checks 

The following must be true for an lOA program to represent a valid composite I/O automaton and 
can be checked statically. These checks are currently performed by ioaCheck, the lOA parser and 
static-semantic checker. 

/ No sort appears more than once in types . 

•/ Each component name (i.e., Ci) occurs at most once. 

/ The sequences vars^ and vars^'^'- of variables contain no duplicates; furthermore, no variable 
appears in both vars and vars ' '■ for any value of i. 



'^^Although Ai, types , d, and actualTypes'^' ' appear as subsorts of a sort constructor States [ , . . .] , lOA 

assigns no semantics to these sorts. Syntactically, however, they are treated in the same fashion as other sorts; in 
particular, the resorting pi replaces types ' by actualTypes^' ' . 
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/ Each component automaton is supplied with the appropriate number of actual types, that is, 
actualTypes ' ' has the same length as types \ 

•/ For every operator / in a theory specified in the assumes clause of the automaton j4j, a 
corresponding operator /Ji(/) must be introduced by a type definition or axioms clause in 
the lOA specification that contains the definition of D, by a theory specified in the assumes 
clause of D, or by a built-in datatype of lOA. 

/ Each component automaton is supplied with the appropriate number and sorts of its other 
actual parameters, that is, actuals ' ' has the same length as vars^' and the same sorts as 
Pi{vars "■) . 

/ Each component automaton is supplied with actual types that do not reduce the number of 
distinct state variables. That is, all selectors of States[Ai, actualTypes ' '] are distinct. 

/ All occurrences of an action name vr in all component automata have the same number and 
sorts of parameters; that is, if vr is an action name in both Ai and Aj, then vars '■''" has the 

Ai,TT\ Tips thp samp sort, as nA Dnr^^l '''^\ 



same length as vars^'"" , and pi{vars ''^) has the same sort as pj{ 



vars 



/ Each action name in a hidden statement must be an action name in some component au- 
tomaton. 

/ All occurrences of an action name vr in a hidden statement have the same number and sorts 
of parameters as the occurrences of the action name vr in the component automata; that is, 
if vr is an action name in some Ai and ir = iTp for the hidden clause p, then vars^'"^ has the 
same length as params^^J^ , and pi{vars '^) has the same sorts as paramSj^-J^ . 

•/ Any variable that occurs freely in a term used as a parameter or predicate, in the definition 
of a composite automaton must satisfy the restrictions imposed by Table |5.1[ 



5.4 Semantic proof obligations 

The following must also be true for an lOA program to represent a valid I/O automaton. Except in 
special cases, these conditions cannot be checked automatically, because they may require nontrivial 
proofs (or even be undecidable); hence static semantic checkers must translate all but the simplest 
of them into proof obligations for an automated proof assistant. [^ 

/ Only output actions may be hidden. 

/ The components of a composite automaton must have disjoint sets of output actions. 

/ The set of internal actions for any component must be disjoint from the set of all actions of 
every other component. 



We will express these these proof obligations in first-order logic in Section 7.4 using syntactic 
forms we define earlier in Section [3 



^*An implementation of these checks might reduce the number of errors reported by first confirming that the 
composition contains no duplicate instances of any component automaton that contains internal or output actions. 
Any such duplication would necessarily cause violations of the latter two checks. 
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6 Expanding component automata 



Before we can describe the contribution of a component Cj of a composite automaton D to the 
expansion of D into a primitive automaton DExpanded, we must take four preparatory steps. The 
result is a component that represents the instantiation of automaton Ai on which Ci is based using 
the actual parameters supplied by the component and whose variables have been translated into a 
unified name space used for DExpanded. 

The first step is to desugar the definition of each component automaton Ai as described in 
Section Ul In the discussion below, we refer to this desugared version of Ai as Ai and assume that 



it satisfies the restrictions listed in Section 4.5 The second step, shown in Section 6.1 , is to replace, 
throughout the entire definition of the automaton Ai, the formal type parameters types ' of Ai 
by the actual types actualTypes ' ' supplied by the component Cj. The third step is to replace 
the formal automaton (non-type) parameters vars '■ by the actual parameters actuals ' ' supplied 
by the component Cj. The fourth step is to translate the aggregate state variables, aggregate 
local variables, and action parameters from the name space of Ai into a unified name space for 
DExpanded. (It is not necessary to translate individual state and local variables, because references 



to them have been eliminated by the desugaring described in Section 4.4) Sections 6.2 describes 



how we choose canonical action parameters for the unified name space. Section 6.3 describes the 
substitution we use to perform both this translation and the instantiation of actual automaton 



parameters for the previous step. Table 6.8 summarizes the notation, figures, and examples we use 
to present these stages. 



Section 6.4 describes the result of applying these replacements and translations to individual 
component automata. It sets the stage Section [7] which describes how to combine the expanded 
components into a description of DExpanded by developing explicit representations for its signature 
and transition definitions. 



6.1 Resorting component automata 

We produce a definition of the instances of Ai whose sorts correspond to those of the component Ci 
by replacing the formal type parameters types "■ of Ai with the actual types actualTypes ' ° sup- 
plied by t he co mponent d. This replacement is accomplished by applying the resorting /jj, defined 
in Section 5.2 to the entire definition of the automaton Ai. The precise definition of resortings and 
a full description of how resortings are extended to perform this replacement throughout the entire 



definition of the automaton Ai are given in Section^ We denote the resulting definition by piAi. 



Example 6.1 Tables 6.1-6.3 show how the resortings p and p , induced by the components 
statement of the sample automaton Sys in Example 2.4, map the sorts, variables, and operators 
of the component automata ^^ The resorted components p Channel and p Watch of the composite 
automaton Sys are shown in Figure 6.1, Since the component automaton P of Sys does not have 



any type parameters, p is the identity, and the resorted component p P is the same as shown in 



Figure 4.8 



^^The table shows only the non-identity mappings of sorts, variables, and operators. Sorts, variables, and operators 
that appear in the sample automata, but are not shown in the table, are mapped to themselves. 
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RESORTING 


DOMAIN 


RANGE 


/ 


Node 


Int 


Msg 


Int 


Set [Msg] 


Set [Int] 


States [Channel, Node, Msg] 


States [Channel , Int , Int] 


P' 


T 


Int 


Set [T] 


Set [Int] 


Array [T, Bool] 


Array [Int , Bool] 


States [Wat ch,T] 


States [Watch, Int] 


Locals [Wat ch,T, overflow] 


Locals [Watch, Int , overflow] 



Table 6.1: Mappings of sorts by resortings in the composite automaton Sys. Resortings listed on 
the left map domain sorts to their right to the range sorts on their far right. 



RESORTING 


DOMAIN 


RANGE 


/ 


i:Node 


i:Int 


j :Node 


j :Int 


contents : Set [Msg] 


contents : Set [Int] 


nl:Node 


nl : Int 


n2:Node 


n2 : Int 


m:Msg 


m:Int 


/ 


what : Set [T] 


what : Set [Int] 


seen : Array [T , Bool] 


seen : Array [Int , Bool] 


x:T 


x:Int 


x:T 


x: Int 


s : Set [T] 


s: Set [Int] 


s2:Set[T] 


s2: Set [Int] 



Table 6.2: Mappings of variables by resortings in the composite automaton Sys. Resortings listed 
on the left map domain variables to their right to the range variables on their far right. 
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RESORTING 


OPERATOR 


ORIGINAL AND NEW SIGNATURES 


/ 


= 


Node.Node^Bool 
Int.Int^Bool 


= 


Msg.Msg^Bool 
Int.Int^Bool 




^Set [Msg] 
^SetClnt] 


G 


Msg,Set[Msg]^Bool 
Int,Set[Int]^Bool 


insert 


Msg , Set [Msg] ^Set [Msg] 
Int , Set [Int] ^Set [Int] 


delete 


Msg , Set [Msg] ^Set [Msg] 
Int , Set [Int] ^Set [Int] 


__. contents 


States [Channel , Node , Msg] ^Set [Msg] 
States [Channel , Int , Int] ^Set [Int] 


P" 


[-] 


T^Bool 
Int^Bool 


{-} 


T^Set [T] 
Int^Set [Int] 


= 


Set[T] ,Set[T]^Bool 
Set [Int] , Set [Int] ^Bool 


G 


T,Set[T]->Bool 
Int,Set[Int]->Bool 


U 


Set[T],Set[T]^Set[T] 

Set [Int] , Set [Int] ^Set [Int] 


__. seen 


States [Watch, T]^Array[T, Bool] 
States [Watch, Int] -^Array [Int , Bool] 


__.s2 


Locals [Watch,T, overflow] ^Set [T] 
Locals [Watch, Int , overflow] ^Set [Int] 



Table 6.3: Mappings of operators by resortings in the composite automaton Sys. Resortings listed 
on the left map domain operators to their right to the range operators on their far right. 
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°L Resorting of Channel for component C of Sys 
automaton Channel (Node , Msg:type, i, j:Int) 
signature 

input send(nl, n2 : Int , in:Int) where nl = i A n2 = j 
output receive (nl, n2 : Int , m:Int) where nl = i A n2 = j 
states contents : Set [Int ] :— {} 
transitions 

input send(nl, n2 , m) where nl = i A n2 = j 

eff Channel . content s := insert (m, Channel . content s ) 
output receive (nl, n2 , m) where nl = i A n2 = j 
pre m G Channel . content s 
eff Channel . content s :— delete (m, Channel . content s ) 

y„ Resorting of Watch for component W of Sys 
automaton Watch (T : Type , what : Set [ Int ] ) 
signature 

input overflow (x : Int , s: Set [Int]) where x G what 
output found (x: Int) where x G what 
states seen : Array [ Int , Bool ] := constant ( false ) 
transitions 

input overflow(x, s; local s2:Set[Int]) 

where s = Watch. s2 U {x} V ^(x G s) 
eff if s = Watch. s2 U {x} then Watch . seen [x] := true 
elseif ^(x G s) then Watch . seen [x] := false 
fi 
output found (x) 

pre Watch . seen [x] 

Figure 6.1: Sample component automata Channel and Watch, obtained by resorting the desugared 



automata shown in Figure 4.8 
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6.2 Introducing canonical names for parameters 

For each action name vr in some component Cj oi D, we pick a sequence vars ''^ of variables to be 
the canonical action parameters of vr in D. Since the static checks ensure the number and sorts of 
variables in pi{vars ''") are the same for all components Q, we take vars^''^ to be pi{vars ''^) for 
the smallest i such that vr is the name of an action in d and this choice does not cause variables 
to clash. In particular, no variable in vars^''^ should be a parameter of D (i.e., vars^''^ and vars^ 
should be disjoint) nor of any component d (i.e., vars ''" and vars ' ' should be disjoint)rj 

If vars^'"^ cannot be defined in this fashion (without causing variables to clash), then we let 
i be the smallest integer such that vr is the name of an action in Cj, and we take vars '"^ to be 
Pi{vars ''^) with any clashing variables replaced by fresh variables, that is, with variables not in 
vars nor any vars ' \ 

6.3 Substitutions 

For each component Cj of a composite automaton D, we define a substitution ai (which we write as 
o" ' in contexts, such as a , where it is more convenient to use the name of the component rather 
than its position in the list of all components) to map the non-type parameters vars'^'- '■ = pi{vars "■) 
of the component automaton piAi to the corresponding actual parameters actuals ' ° and to map 
the aggregate state and post-state variables of piAi to the appropriate state components in the 
composite automaton. For each action vr of Cj, we also define a substitution cTi^-,^ to be the same as 
(Tj, except that it also maps the canonical action parameters vars^^ '''^ = pi{vars "■) of piAi to the 
corresponding canonical action parameters vars^''^ in D, and that it maps the aggregate local and 
post-local variables for transition definitions in piAi to the appropriate local and post-local values 
in the composite automaton. 



These substitutions^^ are summarized in Table 6.4 and defined by rules llflol below. 



1. If a; is a non-type parameter of Ai (i.e., x G vars'^'- '■), then cjipi{x) is the corresponding 
element of actuals^' \ 

2. If Cj has no parameters and x is the variable Ai of sort States[Ai, actualTypes ' '] representing 
the aggregate states of piAi, then (Tj(x) is the state variable for the component Cj of D, which 
has the same sort as A^. 

3. If Cj has parameters and x is the variable Ai of sort States[Ai, actualTypes ' '], then ai{x) 
is the term Ci[vars^ ''-''-], where Cj is the state variable for the component Cj of D, which has 
sort na.pLtypes^''^% States[Ai, actualTypes^''^']! . 

4. If Cj has no parameters and x is the variable A'^ of sort States[Ai, actualTypes ' °] representing 
the aggregate post-states of piAi, then ai{x) is the post-state variable C^ for the component 
d of D. 

5. If Ci has parameters and x is the variable A'^ of sort States[Ai, actualTypes ' '], then (7i[x) is 
the term Cl[vars '^], where C'^ is the post-state variable for the component Ci of D, which 
has sort na.pltypes^''-''\ States[Ai, actualTypes ' ']] . 



^°It is not necessary to avoid clashes with the state variables pi{stateVars ') or post-state variables pi{postVars ') 
of Ci, because desugaring has replaced references to such variables x by terms d.x. 

^^See Sectionlolfor a precise definition of substitutions, which ensures that they do not capture local, for, choose, 
or quantified variables. 
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SUBSTITUTION 


DOMAIN 


RANGE 


RULE 


o-i 


varsP^^^ 


actuals^ '^' 


rule 


1 


Ai:States[Ai, actualTypes ' '] 


a 


rule 


2 


Ai:States[Ai, actualTypes^''^'] 


Ci[vars^'^'] 


rule 


3 


Cfi^TT 


ya^gPi^i 


actuals^ ''^' 


rule 


1 


Ai:States[Ai, actualTypes^''^'] 


Q 


rule 


2 


Ai:States[Ai, actualTypes ' '] 


C^[vars^'^'] 


rule 


3 


A'-:States[Ai, actualTypes^''^'] 


c[ 


rule 


4 


A'fStates[Ai, actualTypes^''^'] 


C'^vars^'(^'] 


rule 


5 


varsP'^"^ 


y(lj-gD,n 


rule 


7 


Ai:Locals[Ai, actualTypes ' ,vr] 


a 


rule 


8 


A'-:Locals[Ai, actualTypes^ '^\tt] 


c[ 


rule 


8 


Ai:Locals[Ai, actualTypes ' ', it] 


Ci[vars^'^'] 


rule 


9 


A'-:Locals[Ai, actualTypes^ '^',7r] 


C'^vars^'^'] 


rule 


9 



Table 6.4: Substitutions used in canonicalizing component automata. Substitutions listed on the 
left map variables in the domains to their right to range variables according to the listed rules. 



6. There is no rulep] [T] 

7. If X is a canonical action parameter (i.e., x E vars '''^), then ai^T^pi{x) is the corresponding 
element of vars^''" . 

8. If Cj has no parameters and x is the variable Ai of sort Locals[Ai, actualTypes ''^"'^] (or the 
variable A'^ of the same sort) representing the aggregate local (or post-local) variables for a 
transition definition, then (Tj(x) is the local variable Ci (or the post-local variable C^) for the 
transition definition in D, which has the same sort as A^. 

9. If Ci has parameters and x is the variable Ai of sort Locals[Ai, actualTypes ' '''"] (or the 
variable A'^ of the same sort), then (Tj(x) is the term Ci[vars^'^'] (or the term C[[vars^'^']), 
where Ci and C[ are the aggregate local and post-local variables in D, which have sort 
V[a.-pitypes^ ''^' , Locals[Ai, actualTypes^''"' , it]'] . 

6.4 Canonical component automata 

For each component Ci of D, we obtain a canonical automaton definit ion Ci for that component 

shows the general form 



6.2 



by applying pi and then ai to the desugared definition Ai of Ai . Figure 
for such canonical component automata. 

In the list of parameters for d, the type parameters types of D replace the type parameters 
types ' of Ai, and the variables vars and vars ' ' that parameterize D and its component d 
replace the individual parameters vars ' of Ai. The body of the automaton definition for Ci is 
obtained by applying the resorting pi to the body of the automaton definition for Ai, thereby 
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eliminating all references to the type parameters in types % to obtain a resorted definition for an 
automaton piAi and then by applying the substitution cjj to this resorted definition, thereby elim- 
inating all references to the individual parameters in vars ^ We do not apply ai to stateVars^^ ', 
because we wish to preserve the names of the state variables in stateVars \ No ambiguity arises, 



because the desugaring described in Section 4.4 has replaced all references to state variables x in 
the definition of Ai with terms of the form Ai.x. For each action vr, we also apply ctj^tt to the where 

clause P, 



kind 



for vr in the signature of piAi and to the transition definition for vr in piAi. 



Despite the absence of ambiguity, the automaton Ci may not pass the static semantic require- 



ments in Section 3.3 that prohibit any clashes between state variables and automaton parameters. 
Furthermore, if Ci has non-type parameters, the aggregate state variable for the automaton is a 



map as specified in Section 5.2 rather than a tuple as specified for primitive automata in Section 3.2 



Table |6.8| shows the steps taken to expand canonical component automata. The "Original" 
column lists the names for syntactic elements of automata introduced in Section [3j The notation 
given in the "Desugared" column describes the result of desugaring such automata as described in 
Section |4j The elements listed in the the "Resorted" column result from the resorting of desugared 
component automata that Section 6.1 describes. Syntactic elements listed in the "Expanded" 
column are derived in Section 6.3 from resorted automata. Finally, names that appear in the 
"Component" column are just synonyms for the values in the previous column. We use these 
simpler synonyms in Section [7| 



automaton Ci{types^ , vars^ , vars^'^) 
signature 

kind Tr{vars^''^) where <yi,-K{P'^lnd'^) 



states stateVarsP'^' := ai{mitValsf'^') initially cri(Pf^,f') 
transitions 

kind 7r(wars^'^"''; local localVarsP'^'^'") where p^'^"'' 



0"i- 



kind,ti 



r>rp PrpP*^*''^ 
pre -rrCj^.^^ 



efF Progi] V^ ensuring ensuringi] V'^ 



Figure 6.2: General form of the expansion of the automaton for component Cj, obtained from the 
desugared definition Ai of the automaton on which Ci is based 



Example 6.2 We derive the component automata C, P, and W of the composite automaton Sys by 
applying the substitutions shown in Tables 6.5-6.7 to the resorted automata p Channel and p Watch 



shown in Figure 6.1 and to the canonicalized automaton P shown in Figure 4.8 Since the per-action 



substitutions (e.g., a 



C,send\ 



are always extensions of the per-component substitutions (e.g., a 



these tables show only the additional mappings that distinguish the per-action substitutions from 
the per-component substitutions. We also omit from these tables identity mappings. For example, 
we omit from Table 6.6 the identity mapping of il:Int to itself due to rule M in (ji^.°vertiow_ T\ie 
resulting component automata are shown in Figures 6.3-6.5 
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automaton C (nProcesses : Int , n:Int) 
signature 

input send(nl, n2 : Int , m:Int) where nl = n A n2 = n+1 
output receive (nl, n2 : Int , m:Int) where nl = n A n2 = n+1 
states contents : Set [Int ] := {} 
transitions 

input send(nl, n2 , m) where nl = n A n2 = n+1 

eff C [n] . content s := insert(m, C [n] . content s ) 
output receive (nl , n2 , m) where nl = n A n2 = n + 1 
pre m S C [n] . contents 
eff C [n] . content s := delete(m, C [n] . content s ) 



Figure 6.3: Sample instantiated component automaton C, obtained by applying the substitutions 



in Table 6.5 to the resorted automaton Channel in Figure 6.1 



SUBSTITUTION 


DOMAIN 


RANGE 


RULE 


a^ 


Channel : States [Channel , Int , Int] 


C [n] : Map [Int , States [Channel , Int , Int] ] 


rule 


3 


i:Int 


n:Int 


rule 


1 


j :Int 


(n+1) :Int 


rule 


1 


^C,send 


No additional substitutions 


^C, receive 


No additional substitutions 



Table 6.5: Substitutions used to derive sample component automaton C. Substitutions listed on 
the left map variables in the domain to their right to variables in the range their far right. 



SUBSTITUTION 


DOMAIN 


RANGE 


RULE 


aP 


P: States [P] 


P [n] : Map [Int , States [P] ] 


rule 


3 


^P,send 


il:Int 


nl : int 


rule 


7 


12 : Int 


n2 : int 


rule 


7 


x:Int 


m: int 


rule 


7 


^P, receive 


il:Int 


nl : int 


rule 


7 


12 : Int 


n2 : int 


rule 


7 


x:Int 


m:int 


rule 


7 


^P, overflow 


P : Locals [P , overflow] 


P [n] : Map [Int , Locals [P , overflow] ] 


rule 


9 



Table 6.6: Substitutions used to derive sample component automaton P. Substitutions listed on 
the left map variables in the domain to their right to variables in the range their far right. 
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automaton P (nProcesses : Int , n:Int) 
signature 

input receive (nl, n2 , m:Iiit) where nl = n-1 A n2 = n 
output send(nl, n2 , m:Int) where nl = n A n2 = n+1, 
overflow ( il : Int , s: Set [Int]) where 11 = n 
states 

val : Int :— , 
toSend : Set [Int] := {} 
transitions 

input receive (nl, n2 , m) where nl = n-1 A n2 = n 
eff if P[n].val = then P [n] . val := m 
elseif m < P [n] . val then 

P[n].toSend := insert (P [n] . val , P [n] . toSend ) ; 
P [n] . val :— m 
elseif P [n] .val < m then 

P[n]. toSend := insertCm, P[n]. toSend) 
fi 
output send(nl, n2 , m) where nl = n A n2 = n + 1 
pre m e P[n]. toSend 

eff P[n]. toSend := delete(m, P[n]. toSend) 
output overflowdl, s; local t:Set[Int]) where 11 = n 
pre s = P[n]. toSend A n < size(s) A P [n] . t C s 
eff P[n]. toSend := P [n] . t 



Figure 6.4: Sample instantiated component automaton P, obtained by applying the substitutions 



in Table |6.6| to the automaton P in Figure 4.8 



automaton W (nProcesses : Int ) 
signature 

input overflow ( il : Int , s:Set[Int]) where 11 G betweend, nProcesses) 
output f ound ( il : Int ) where 11 G betweend, nProcesses) 
states seen : Array [ Int , Bool ] := constant ( false ) 
transitions 

input overflowdl, s; local s2:Set[Int]) 
where s = W.s2 U {11} V ^(11 G s) 
eff if s = W.s2 U {11} then W.seen[il] := true 
elseif ^(11 G s) then W.seen[il] := false 
fi 
output founddl) 
pre W . seen [il] 



Figure 6.5: Sample instantiated component automaton W, obtained by applying the substitutions 



in Table 6.7 to the resorted automaton Watch in Figure 6.1 
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SUBSTITUTION 


DOMAIN 


RANGE 


RULE 


a" 


Watch : States [Watch , Int] 


W: States [Watch, Int] 


rule 


2 


what : Set [Int] 


betweenCl, nProcesses) 


rule 


1 


W,overf low 


Watch : Locals [Watch , Int , overflow] 


W: Locals [Watch, Int , overflow] 


rule 


8 


x: Int 


i 1 : int 


rule 


7 


^W, found 


x: Int 


il:Int 


rule 


7 



Table 6.7: Substitutions used to derive sample component automaton W. Substitutions listed on 
the left map variables in the domain to their right to variables in the range their far right. 
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7 Expanding composite automata 

In this section, we present the main contribution of this document. We show how to expand a com- 



posite lOA program into an equivalent primitive lOA program. Section 7.1 reviews our assumptions 
about the form of the components of the composite automaton, and Section 7.2 describes a simph- 
fication of the structure of hidden statements, obtained by combining ah clauses for a single action 
into a single clause. 



In Section 7.3 we define the expansion of the signature of a composite automaton to primitive 
form. Section 7.4 gives first-order logic formulas for the semantic proof obligations we introduced in 

we 



Section 5.4 These include compatibility requirements for component automata. In Section 7.5 



define the expansion of the initially predicate on states of a composite automaton. In Sections 7.6 



7.9, we define the expansion of the transitions of a composite automaton. 



7.1 Expansion assumptions 

We expand a composite automaton D into primitive form by combining elements of its components 
Ci , . . . , Cn . W e assume each component automaton Ai has been desugared to satis fy th e restrictions 
in Section 
transformed as described in Section 



4.5, resorted to produce an automaton piAi as described in Section 5.2 and 6.1, and 



6.4 



to produce an automaton aiPiAi = Ci. In particular, for 



each component automaton Cj, we assume the following. 

• No const parameters appear in the signature. 

• Each appearance of an action vr in the signature is parameterized by the canonical action 
parameters vars '^. 

• Each transition definition of an action vr is parameterized by the canonical action parameters 

D TV 

vars ' . 

• Each transition definition of an action vr is further parameterized by the canonical sequence 
(^i,TTPi localVars '''^ of local variables for that component. 

• Each action has at most one transition definition of each kind. 

• Every state, post-state, local variable, or post-local variable reference is of the unambiguous 
form Cj.x, C'^.x, Ci[vars^'^^].x, or Cl[vars^'^'].x. 

7.2 Desugaring hidden statements of composite automata 

The syntax for composite lOA programs as described in Section |5] provides programmers with flex- 
ibility of expression that can complicate expansion into primitive form. Hence, as with primitive 
automata, it is helpful to consider equivalent composite lOA programs that conform to a more 
limited "desugared" syntax. As discussed later in this section, where clauses of composite au- 
tomaton hidden statements and of component transitions are combined during expansion. Thus, 
hidden statements must be desugared into a form analogous to that of a desugared transition. 
In particular, we desugar composite automata with hidden statements to have the following two 
properties. 

• Each hidden clause for an action it is parameterized by the canonical action parameters 



vars 
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There is at most one hidden clause for each action vr. 



The static checks described in Section 5.3 ensure that the number and sorts of terms in paramSf^-'J^ 
are the same as the number and sorts of variables in vars ''"^ . If no variable in vars ''^p occurs 



D,n 



freely in paramSf^-^^ (i-e., if vars ''^^ and varSf^^-'^^ are disjoint), then we can desugar the clause 



TTpiparams^^l^) where ^^^^"j 



by replacing po-'ra'ms ^^^J^ by vars^''^f, reintroducing vars^^J^ as existentially quantified variables 
in the where clause, and adding conjuncts to the where clause to equate vars^''^p with the old 
parameters. This results in the desugaring 



-KrAvars 



^'-^) where 3 mr^S,?^ [h^Z A vars^^^^ = paramsf^^l) 



Notice that introducing vars^^-j^^ as existentially quantified variables is analogous to introducing 

varSj^^^, as local variables when desugaring transition parameters, as described in Section 4.1 

If vars^''^'' and vars^^J^ are not disjoint, we define a substitution a^^'^'^ that maps the intersec- 
tion of these two sets to a set of fresh variables, and we desugar the hidden clause as 

vr,(mr.^.-^) where 3 af'^vars^^^^ (^p'^'^^S A vars^^^^ = a'^''' params^Z) ■ 

We simplify each existentially qualified where clause produced by the above transformations 
by dropping any existential quantifier, such as 3 i:Iiit in the example, that introduces a variable 
equated to a term, as in i = x in the example, in the conjunction vars ''^p = ap params j^-'^J , and 



also by dropping the equating conjunct from that conjunction. We denote the resulting simplifica- 
tion of the where clause by HJ^.Z,, canon- 

Following this clause- by- clause canonicalization, we combine all clauses in the hidden statement 
that apply to a single action vr into one disjunction. This step is analogous to the combining step 



for transition definitions in Section 4.3, For example, if vTp = tt^ = vr, then the clauses 



vr,(ws^'-^) where i7,^:;_„„ 
7r,(mr.^''^^) where i/,^,;%,_ 
become the single clause 



TT(vnr^^''^'\ where U^''^'' y o-^.Tg 

-K^uarb ) ^'^'■^'■^ J^hidep, canon ^ ^hideg,canon- 

We denote this combined where clause by H^''^. 

7.3 Expanding the signature of composite automata 

In the composite automaton D, actions that are internal to some component are internal actions of 
the composition, actions that are outputs of some component and are not hidden are output actions 
of the composition, and actions that are inputs to some components but outputs to none are input 
actions of the composition. The where clause predicates -P^j^^ express these facts in the signature 
of the expanded automaton D Expanded. We construct these predicates by defining subformulas, 
^kind''" and Provj^^^^ which describe the actions components contribute to the composition. We 
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automaton DExpanded{types , vars ) 
signature 

kind TT{vars^''^) where -P^j^^ 

Figure 7.1: General form of the signature in the expansion of a composite automaton 



combine these formulas and the where predicate from any applicable hidden clause (i.e., iJ^''^), 
to account for the subsumption of input actions by output actions and for hiding output actions. 
The final result consists of the three predicates P^n^ , Pout i ^^"^ ^inf ■ 

All free variables that appear in these predicates are among the composite automaton parame- 



ters vars and the canonical action parameters vars ''^ . Figure 7.1 shows the general form of the 



expanded signature. Below, we explain how to construct these predicates. (See Section 8.2 for an 
example application of the process to composite automaton Sys defined in Example |2.4[ ) 

Subformulas for actions contributed by a component 

In order for an action kind 7:{vars^''^) to be defined in D, it must be defined in some component. 
An action is defined in a component Cj of D if, given action parameters vars^''^ there are component 
parameters vars ' '- that satisfy both the component where clause P^''-'^ and the action where 
clause -Pj.j^'J for vr in the signature of Cj. Hence we define 

^il;?''^ ■■■■= ^vars^'""' (P^'^ A P^), 

which is satisfied by vars ''^ if and only if TT{vars ''^) is an action of type kind in component Cj of 
D. 

It is important to note that the type of the action -K^vars^''^) in D may be different from the 
type of vr in some, or even all, the components contributing the action to the composition. Output 
actions in one instance of one component may subsume inputs in another, and output actions may 
be hidden as internal actions in the composition. We say that kind is the provisional kind of 
Tr{vars ''") in D when an action of that kind is contributed to the composition by some component. 
Hence we define the predicate Pi"0Vf^^^^ as follows: 



^™^tod "= V ^k 



kind 
l<i<n 



Signature predicates 

We account for subsumed inputs and hidden outputs in the signature of DExpanded by appending 
special case formulas to the predicates Prov^^^ to form the signature predicates -P^j^^. The three 
cases we must consider are: 

• An action n^vars^''") is an output action of D if and only if it is an output action in some 
component Cj of D and is not hidden in D. 

• An action n^vars^''^) is an input action of D if and only if it is an input action in some 
component d of D, but not an output action in any component of D. 
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• An action TT{vars^''") is an internal action of D if and only if it is an internal action, or a 
hidden output action, in some component d of D. 

Translating these requirements into first-order logic, we derive the following definitions for the 
signature predicates of DExpanded: 

. P^^r ::= Pro.f„f V [Prov^^^ A H^'^) . 

7.4 Semantic proof obligations, revisited 

We are now ready to formalize the following proof obligations on composite automata introduced 
in Section [5741 



/ Only output actions may be hidden. 

/ The components of a composite automaton have disjoint sets of output actions. 

/ The set of internal actions for any component is disjoint from the set of all actions of every 
other component. 

Below we give corresponding formulas in first-order logic that must be verified for a composite 
lOA program to represent a valid I/O automaton. In order to express the latter two of these 
obligations in first-order logic, we break each of them into two parts. First, we consider different 
components from different clauses of the components statement (i.e., Cj 7^ Cj). Second, we 
consider instances of the same parameterized component distinguished only by parameter values 
(i.e., Ci[vars^''-^'] 7^ Ci[vars'^'^']). We use these formulas to help construct the expansion of 



transitions of composite automata in Sections 7.7-7.9 



Hidden actions 

The first of these obligations is just the requirement that 

Output actions 

For output actions, we first require that different parameterized components have disjoint sets of 
output actions. Formally, we say that for all distinct components Cj and Cj of D, all values of the 
action parameters vars ''^ for vr, all values of the composite automaton parameters vars , and all 
values of the component parameters vars^'^^ and vars^'^^ , we require that 

/ .P«f '- V ^Pif-'^ (7.1) 

Second, we require that different instances of the same parameterized component have disjoint 
sets of output actions. That is, for each component Cj of D, all values of the action parameters 
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vars^''^ for vr, all values of the individual parameters vars^ of the composite automaton, and all 
pairs of values of the component parameters vars ' ' and vars ' % we require that 

/ (P^'^' A P'^'^' A P„^f A P'f^f ) ^ vars^'^' = vars'^'^^ (7.2) 



where P' out i^ Pouf evaluated on vars'^''^\ 

In Example |2.4[ these requirements are satisfied trivially, because the output actions in the 
different components of Sys have different labels. However, the composition 
automaton BadSysl 

components Pl[n:Int] where 0<nAn<10; 
P2 : P(5) 
would violate the first requirement, because components PI [5] and P2 share an output action, and 
the composition 

automaton BadSys2 

components W [what : Set [Int ]] : Watch(Int, what) 

where what — between (1,1) V what = between (1,2) 
would violate the second requirement because components W[[l]] and W[[l,2]] both have found(l) 
as an output action. 

Internal actions 

Similarly, we break the last of these semantic proof obligations, which concerns internal actions, into 
two parts. We first require that internal actions are defined in one component only for parameter 
values where no action is defined in any other component. Formally, we say that for all distinct 
components Ci and Cj of D, all values of the action parameters vars^'"^ , and all values of the 
composite automaton non-type parameters vars , we require that 

^ p!^"'' ^ -Pl^f"'' (7.3) 

where P^^ ^' is the disjunction of P^^ ^' , P^^t ^' ) and P^^^ ^' . 

Second, we require that internal actions of one instance of a parameterized component are 
defined only for parameter values where no action is defined in any other instance of that component. 
That is, for each component Cj of D, all values of the action parameters vars^''^, all values of the 
composite automaton non-type parameters vars , and all pairs of values of component non-type 
parameters vars^''-"'^ and vars'^'^% we require that 

/ (P^'^' A P'^'^' A P,^f A P'^V") => vars'''^^=vars"''^\ (7.4) 

where P' Ji^ is the disjunction of P'^^'^ , P' out ^ ^^^ P' int" and where the primed form of each 



predicate is the evaluation of the predic ate o n vars 

int in int out 



Note, although allowed by obligation |7.4l the cases where Pj„V'^ A Pj '''^ or Pj„V'^ A Pg^f ^old 



are already disallowed by semantic proof obligations 4.2 and 4.3 respectively. 



Claim 1 (Signature compatibility) Semantic proof obligations 7.1-7.4 taken together with the 
signature where predicates i 
primitive automata |4. lH4?3l 



signature where predicates Pj^i^d i™ply that DExpanded fulfills the semantic proof obligations for 



In Sections 7.7-7.9 we argue that remaining obligations for primitive automata (4.4 and 4.5) 



are discharged by the transition where clauses of DExpanded. 
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7.5 Expanding initially predicates of composite automata 



In Section p.2[ we described the state variables of a composite automaton D. Corresponding to each 
component C, is a state variable Q with sort States[Ai, actualTypes ' '] if Cj has no parameters and 
with, sort na.Tpltypes'%States[Ai,actualTypes ' ']] otherwise. Here, we describe the construction 
of an initially predicate that constrains the initial values of these state variables. This predicate is a 
conjunction of clauses, one per unparameterized component and two per parameterized component. 
If a component Cj is not parameterized (i.e., the state variable Ci is a tuple, not a map), then 
a single clause asserts that, for all values of the component parameters for which the component 
is defined (i.e., when P^''-'^ is true), each element of the tuple has an appropriate initial value. 
Furthermore, the clause asserts that, when P^^^^ is true, the tuple as a whole satisfies the initially 
predicate P^:^^^ of the component. In order to account for initial values specified as non deterministic 
choices, we proceed as follows. Let 

• Xi be the set of indices k of state variable declarations of the form 

Xk-Tk ■■= choose Vk'.Tk where P^^f-p. 
in the definition of the component Cj, 

• cVars^ be a set of distinct fresh variables v'j.:T}^, one for each /c in Xj, 

• *initVals ' be initVals ' with each of the above choose expressions replaced by the corre- 
sponding v^:Tfc for each k in Xi, and 

• *Pij^n /j be i^j„'j^ f^ with u^ substituted for Vk when k € Xi and the predicate true otherwise. 



Then we formulate the clause (shown in Figure 7.2) corresponding to Ci in the initially predicate 
of D Expanded by factoring out, and existentially qualifying, the variables (i.e., cVars ') used to 
choose nondeterministic values for the state variables of the component automaton Q. 

When a component Ci is parameterized (i.e., the state variable Ci is a map, not a tuple), then 
there are two clauses for the component. The first is analogous to the single clause for the simple 
case in which the state variable is a tuple, but now it asserts that each element of each tuple in the 
map has an appropriate initial value and that, when P^^'^^ is true, the map as a whole satisfies the 
initially predicate of the component. The second clause asserts that the map is defined exactly for 
the values of the component parameters for which the component itself is defined (i.e., when P^'^^ 
is true). This second clause is also asserted automatically as an invariant of the automaton. That 



is, no transition either extends or reduces the domain over which the map is defined. Figure 7.2 
summarizes these two cases and the invariant. 

7.6 Combining local variables of composite automata 

Just as it helped to collect the local variables from all transition definitions for an action vr when 



desugaring a primitive automaton (see Section 4.3), it helps to collect the local variables from the 



transitions definitions from different components for an action vr when expanding the definition of 
a composite automaton. Hence, we parameterize every transition definition by n per-component 
aggregate local variables that are named for the components Ci, . . . , C„ just as the n per-component 



aggregate state variables are named for those components (see Section 5.2). 
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states 

. . . , 

Cf States[Ai, actualTypes ' °], % if vars^''^^ is empty 

. . . , 

Cj-.na.-plvars^''^^ , States[Aj, actualTypes '•']], % if uars-^''-^J is not empty 

initially 

... A 

P^'^'^3cFars^'(p,^;, A d.stateVars^^ = *initVals^' A AfceX, *^nit,fc) ^ 

... A 

Mvars^^'^J (P^'<^J <^ def ined((7j[wars^''^^])) A 
invariant of DExpanded : 

yvars'^''^! (■p£',Cj ^ defined{Cj[vars^''^i])) ; 
Figure 7.2: General form of the states in the expansion of a composite automaton 
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The sort of each per-component local variable depends on the name of the action and the param- 
eterization of the component. If the component d has no parameters, then the aggregate local vari- 
able Ci has sort Locals[Ai, actualTypes ' ,vr]. On the other hand, if the component Cj has param- 
eters, then the aggregate local variable Ci has sort na.pUypes^''^\ Locals[Ai, actualTypes ' ',7r]], 
where types '' is the sequence of types of the variables in vars ' \ 

We define localVars ''^ to be the sequence of the per-component local variables Ci, . . . , C„. If 
a transition vr has no local variables in component Cj or if vr is not a transition in component Ci, 
we omit Ci from localVars ''" . We also define the sort Locals[D, types^,TT] to be a tuple sort with 
selection operators that are named, typed, and have values in accordance with the variables in 
localVars^'''. 

7.7 Expanding input transitions 

Composition combines the transitions for identical input actions in different component automata 
into a single atomic transition. An input transition is defined for an acti on tt exactly for those 



values of vars^'"^ that satisfy the signature where predicate -Pj^'^^. Figure 7.3 shows the general 
form for the definition of a combined input transition based on this observation. Below, we discuss 
the definitions of the where, efF, and ensuring clauses which appear in that figure. 

Each of these clauses also appears as part of the expanded transitions for output and internal 

in,ti ' 



transitions, so we name them -?■ 'f , Prog- '^, and ensuring- '^, respectively, and include them in 



the figures for the output and internal transitions only by reference. In those transitions, -Pj„'^ 



refers only to the predicate explicitly appearing in Figure |7.3[ That is, without the implicitly 
conjoined signature predicate -Pj„''^. 



transitions 



input TT{vars^''^; local localVars '^) where f\i<:i<n^int "'^ 
efF 



% When vars '^ is empty 

if pD,c, ^ p^^-'^ then Prog, ^"^ fi; 



% When vars^'^^ is not empty 

for vars^''^! where P^^'-^i A -Pj^^''^ do 

Prog^n^ 
od; 

ensuring Ai<i<n ensuring -^^ "'" 
Figure 7.3: General form of an input transition in the expansion of a composite automaton 
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^vhere clause 

Since there is only one input transition for the action tt in DExpanded, the expanded transition 



where clause trivially satisfies semantic proof obligation 4.5 and its only functional role is to define 
the initial values of the local variables localVars ''^ that correspond to a given sequence of action 
parameters vars^''^ . While the signature where predicate P^^'" need only establish that there exists 
some instance of some component that contributes an input action -K^vars ''^), the transition where 
predicate must define local variable initial values for each contributing instance of all contributing 
components. 

We define the input transition where clause -Pj„'J^ by constructing subformulas -Pj„'j "'^. Each 
such subformula constrains the init ial v alue of one local variable Ci of contributing component Cj. 



The where clause shown in Figure 7.3 is then just the conjunction of these predicates P^nt ''^ ^°^' 
all components. 

The subformula P^n't "'^ ^^ ^^^ implication that for each instance of the component that con- 
tributes to the transition, the local variable Cj satisfies the proper initial constraints. The initial 
value of local variable Ci in localVars ''^ is properly constrained when it satisfies the where clause 
^in't ^°^ ^^^ input transition definition of vr in component Ci (for the given values of the compo- 
nent parameters vars '^ and action parameters vars ''"). Thus, the consequent of the subformula 
implication is Pi^'t^- 

When the component is parameterized, the local variable Cj is a map and each entry Ci[vars^'^^] 
in that map corresponds to the aggregate local variable for one instance of the component. In this 
case, the initial values for entries corresponding to all contributing instances must initialized. An 
instance of component d contributes to the transition 7r{vars '^) when component parameters 
vars^'^^ satisfy both the component where clause P^'^^ and the signature where clause Pi^''^ in 
that component (for the given values of the action parameters vars ''"). Thus, the antecedent of 
the implication is the conjunction of these two predicates. To cover all instances, the implication 
is universally quantified over all values of the component parameters vars^'^'-. Hence, we define 

P^S^ ::= V w.^'^» ((P^.^- A P^-) ^ P£- 



Since component Ci satisfies the semantic proof obligation 4.4 there must exists a value for local 
variable Ci that satisfies the above consequent whenever the antecedent holds. Thus, the implication 
is always true when read with the existential quantifier over the local variables localVars ''^ that 
is implicit in the transition header. Thus, DExpanded also (trivially) satisfies semantic proof 



obligation 4.4 for input transitions, since whenever the input action TT{vars ''") is defined in the 
signature of DExpanded, the input transition -K^vars ''") is also defined. 

Notice that for each distinct value of vars^''-^' the predicate Pj^'i'^ mentions a distinct local 
variable Ci or Ci[vars ' '] in localVars ''^. So, the truth values of instantiations of the the impli- 
cation are independent even though there is only one existential instantiation of the local variables 
localVars^ '"". 

However, the fact that the implication is always true does not mean that it is equivalent to 
omit the expanded transition where clause. It is a consequence of the expanded signature where 
clause Pin'^ that some value of vars '^ satisfies the above implication antecedent. In that case the 
where clause asserts that the initial value of the relevant local variable must satisfy the contributing 
component transition where predicate Pinf ■ 

When the component is not parameterized, Pin't^'^ reduces to Pin't^- To see this, first, note 
that the universal quantifier simplifies away for lack of variables to quantify. Second, note that 
pD,Ci g^j^j Pj„"'^ are true whenever Pj„''^ is true. So the implication reduces to just the consequent. 
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Since the only functional role of the where clause is to define the initial values of the local 
variables localVars ''^, when there are no local variables or when no local variable appears in any 
Pin"'^ 1 the where clause can be omitted altogether. 

eff clause 

The eff clause performs the effects of all input transitions of each contributing instance of all 
contributing components. It contains a conditional statement for each unparameterized component 
Ci of D and a loop statement for each parameterized component Cj of D. 

The predicate in the conditional statement for an unparameterized component Ci (when im- 
plicitly conjoined with the where clause for the entire transition and where clause for the action 
in the automaton signature) is true if Ci contributes an input transition for vr to the composite 
automaton D. In that case, the body of the conditional statement executes the program in the eff 
clause in the transition definition for vr in Cj. 

The situation is slightly more complicated when the component d is parameterized, because the 
transition must execute the effects of all instances of the component that contribute to the action. 
Thus, the eff clause loops over all the different values of the component parameters vars ' '- that 
satisfy the component where clause P^^^^ and the signature where clause Pi^'^ in that component 
to execute the program in the eff clause in the transition for vr in that instance of component Ci. 
Notice that each instance of a contributing component Ci (corresponding to one iteration of the 
loop for Ci) manipulates a distinct tuple of local variables Ci[vars^''-^^].'^'^ 

If only one unparameterized component d contributes to the input transition definition, the 
conditional statement for that component may be replaced by the eff clause in the transition 
definition for vr in d itself because the guard is implied by Pin^ ■ 

ensuring clause 

The ensuring predicate must be true if and only if the ensuring predicate from each contributing 
instance of all contributing components is true. That is, given the parameters vars^'"^ , for each 
sequence of values of component parameters vars ' ' of each component Ci that satisfies both the 
component where clause P^'*^* and the signature where clause -Pj„"'^ in that component, the value 
of the local variable Ci in localVars ''^ must also satisfy the ensuring clause ensuring^^'^ for the 
input transition definition of vr in Cj. Thus, we define the predicate ensuring ^^^ "'^ analogously to 
the the predicate Pi^t^''^'- 



ensuring j^^ ::= v vars ' ' I (P ' ' A Pj„ 1 =^ ensuring ^^\] 



^■^ Currently, lOA syntax permits only a single single loop variable in for statements. However, if 1/ is a sequence 
of variables V\,V2,V3, . . . , then it is simple to rewrite multi- variable loops such as the ones used in Figure [tTs] 

for V where p do g od 

as nested single-variable loops using the inductive step 

for v\ where 3V'p do 

for V' where p do g od 
od 

where is the variable sequence V' = V2,Vi ■ ■ ■ , p ^s a. predicate and g is a program. 

58 



7.8 Expanding output transitions 

We build up to the general form of expanded output transitions by first considering three spe- 
cialized cases. The simplest case we consider is an output transition that appears in exactly one 
unparameterized component and in no component as an input transition. Second, we consider the 
expansion of an output transition when that sole contributing component is parameterized. Third, 
we extend our definitions to apply output transitions contributed by multiple components. Finally, 
the fully general expansion of output transitions covers the case where output actions and input 
actions share a name. 

Output-only transition contributed by a single unparameterized component 

We begin by considering the simplest case of an output transition ir^vars ''^) that appears in exactly 
one unparameterized component Cj and in no component as an input transition. That is, there is 
no component Cj, whose signature contains an input action 7:{vars '^). In this case, the expanded 
output transition does not need to be performed atomically with any input transition. 

As there is only one transition contributing to the expansion, there is only one transition for the 
action 7r{vars^''^) in DExpanded. Thus, the expanded transition where clause trivially satisfies 



semantic proof obligation 4.5 and its only functional role is to define the initial values of the local 
variable Cj that corresponds to a given sequence of parameters vars^''^ . In this case, simply reusing 
the component transition where clause Pg^t^i^ as the expanded transition where clause gives the 
correct definition. In fact, the only difference between the expanded transition and the component 
transition in this simplest case is the way locals variables are declared in transition header. The 
aggregate local variable of the component transition becomes the sole local variable of the expanded 



transition. The resulting form is show in Figure 7.4 



transitions 



output 7r(local wars^'*-^', Ci:Locals[Ci, actualTypes ' \tt]) 



where P^^i^t^ 

pre Pref;f 

efF Prog^-,'' 

ensuring ensuring ^^^ 

Figure 7.4: Expanded transition for an output action with no matching input actions, derived 
uniquely from a component d with no parameters. 



Output-only transition contributed by a single parameterized component 

When the component Cj has parameters the expansion is slightly more complicated. As in the 
previous case, no like-named input transitions exist in any component and, therefore, the expanded 
output transition does not need to be performed atomically with any input transition. Also like the 
previous case, there is only one transition definition for n^vars ''^) in the expanded automaton, so 
the transition where clause trivially satisfies semantic proof obligation |4.5| and its only functional 
role is to define the initial values of the local variables. Unlike the previous case, the state and 
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transitions 



output ■n{vars^'^\ local vars^'^\ Ci:Kajp[types^''^\ Locals[Ci, actualTypes^'^% tt]]) 
where P^'^' A P^^ A P^^ft. 
pre Pref;f 
efF Prog^-,'' 

ensuring ensuring ^^^ 

Figure 7.5: Expanded transition for an output action witli no matcliing input actions, derived 
uniquely from a parameterized component Cj. 

local variables Cj are maps rather than simple tuples and the contributing component parameters 
vars '^ are introduced as local variables. 

The initial values of vars ' "■ need to be the correct indices for the relevant entry in the state and 
local variable maps. That is, Ci^vars^'^"^] should evaluate to the tuple derived from the aggregate 
variable of the contributing instance of the component. Note, the semantic proof obligation |7.2| 
requires that at most one instance of a component may contribute an output action 7r{vars ''^). 



In fact, proof obligation 7.2 provides the formula for selecting the correct indices. The component 



parameters of the sole contributing instance uniquely satisfy both the component where clause 
pD,Ci g^j^j |-]^g signature where clause Pouf ■ Thus, these two predicates appear as conjuncts in 
the where clause. 

Since at most one instance of component Cj contributes to the expanded transition, at most 
one entry in each of state and local variable maps Cj, corresponding to the aggregate variable of 
the contributing instance of the component, has any relevance to the transition. The other entries 
are completely ignored, ■^^ The initial values for that entry CAvars^'^^] are those that satisfy the 

C TT 

component transition where clause P^^l j^ . Thus, this predicate forms the last conjunct in the 
expanded where clause. 

The fact that at most one instance of component Cj contributes to the expanded transition 
also means the expanded definition for the transition of an output action vr need not use a for 
statement, as does the expanded definition for the transition of an input action. Instead, the 
expanded definition simply reuses the efF clause of the sole contributing component transition. 
Similarly, the pre and ensuring clauses of the expanded transition are the same as those of the sole 



contributing component transition, as shown in Figure 7.5 



Output-only transitions contributed by multiple components 

When an output action name appears in several components, it would be valid for the expanded 
composite automaton to include a separate output transition derived from each contributing com- 
ponent transition using the above definitions. Unfortunately, as we see below, this approach yields 
a code-size explosion multiplicative in the number of like-named input and output transitions. To 
avoid this code explosion, we define the expanded composite automaton to combine all like-named 



^^In this special case, the references to local variable maps (rather than simple tuples) introduced by substitution 
(Ti^vr rule [9] in Section [6. 3| are actually an unnecessary complication. However, they are required in the more general 
cases discussed below. 
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out 



transitions 

output TT{vars^''^; local vars^'^' , ■ ■ ■ , vars^''^"-, localVars ''^) 
where Vi<.<„, (P^'^' A P^i^ A P^l^^ 
pre Vi<.<„ {P'"'''' A P„^r A Pre^^ 
eff 

if ... 

elseif P^'^' A P„';;f then Progf^f 

elseif . . . 

fi 



ensuring Ai<»<n (^ A P„„7|;^ ^ ensurmg^^^ 

Figure 7.6: Expanded transition for an output action witli no matcliing input actions, contributed 
by several components 



output transitions into a single output transition, as shown in Figure 7.6, An additional advantage 



of combining all like-named output transitions is that, once again, the expanded transition where 



clause trivially satisfies semantic proof obligation 4.5 and its only functional role is to define the 
initial values of the local variables. 

In the expansion, we declare as local variables the parameters of each (contributing) component 
and the local variable Cj from each (contributing) component. As in the previous case, the semantic 
proof obligations for output actions given in Section [7!4]provide the key to defining the where clause. 
Obligation 7.1 requires that for any value of parameters vars^''^ , at most one disjunct of 



V ^oY'" = V 3--^'^' (^^'^' A P^;f) 



l<i<n l<i<n 



can be true. That is, at most one component may contribute an output transition ir^vars ''^). 
Since, all the component parameters vars^'^^ appear as local variables in the expanded transition 
header, these variables are implicitly existentially quantified in the where clause. Therefore, in the 
expanded transition, the above obligation can be expressed simply as 



V ip""''' A p^n- 



l<i<n 



Similarly, obligation 7.2 requires that at most one set of values for the component parameters 
vars^'^^ of that contributing component Ci satisfies the conjunction 

pD,Ci A pCi,n 
^ '^ ^out • 

That is, at most one instance of that component may contribute an output transition -K^vars ''"). 
Notice that this conjunction appears exactly in the previous obligation. In fact, we use the conjunc- 
tion of the component where clause P^''-'* of the contributing component and the signature where 
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clause Poui^ as a "guarding conjunction" for selecting the contributing instance of the contributing 
component throughout the expanded output transition. 

In the where clause the guarding conjunction is paired with the corresponding component tran- 
sition where clause and that triple conjunct is disjoined over all the components. Doing so has the 
effect that the initial values of the relevant local variable Ci (or its relevant map entry Ci[vars ' ']) 
satisfies the component transition where clause whenever Cj is the contributing component. 

Notice, it is a consequence of the expanded signature where clause Pout' that some value of 
' ' satisfies the guarding conjunction. Furthermore, since component Ci satisfies the semantic 



vars 



proof obligation 4.4 there must exists a value for local variable Ci that satisfies the consequent 
whenever the guarding conjunction is true. Therefore, whenever the output action 7r{vars '^) is 
defined in the signature of DExpanded, the output transition 7r{vars^''") is also defined. Thus, 



DExpanded also satisfies semantic proof obligation 4.4 for output transitions. 

In the precondition, the guarding conjunction is paired with the corresponding component 
precondition and that triple conjunct is disjoined over all the components. Thus, the expanded 
transition is enabled when there is a component for which all three of the transition precondition, 
the transition where clause, and the component where clause are true for the given parameters 
and initial local variable values. Checking the conjunction of all three predicates avoids enabling 
the transition when the where clause is satisfied by the transition from one component while the 
pre clause is satisfied by the transition of another component. 

In the eff clause, the guarding conjunction selects the conditional branch containing the effects 
of the single contributing output transition that is defined for the given parameters. Similarly, the 
ensuring clause of the contributing output transition must be satisfied. 

Output transitions subsuming input transitions (general case) 

When both input and output transitions are defined and (the output transition is) enabled, the 
output transition subsumes the input transitions. That is, the input actions execute atomically 
with the output action. Just as we cannot statically decide that two input actions will never 
be simultaneously executed, we cannot, in general, statically decide that an input transition can 
never be subsumed by a like-named output transition. Therefore, each expanded output transition 
must include the effects of all like-named input transitions (appropriately guarded). (It is this fact 
that would cause the code-size explosion mentioned in the previous section were we to include a 



separate output transition derived from each contributing component transition.) Figure 7.7 shows 
the general form for expanding output transitions of composite automata. 

In the cases where the output transition subsumes one or more input transition, the local 
variables from the instance(s) of the component (s) contributing the input transition(s) must be 
initialized by the expanded transition where clause. On the other hand, the where clause must 



still always be satisfiable when an output action is defined. As we argue in Section 7.7 the 



expanded input transition where predicate P^^'t does exactly these two things. First, it requires 
the local variables derived from contributing input transitions to satisfy the where clauses of those 
transitions. Second, Pj^'J^^ is satisfiable by some choice of values for localVars ''^. Thus, we simply 

conjoin -Pj„'J^ to the where clause developed in the previous case. 

The efF clause selects the effects of the single contributing output transition that is defined 
for the given parameters and then performs all the effects of the subsumed input transitions by 
executing Prog^^^ . Each effect in Prog^^^ is already guarded so as to occur only when the source 
transition contributes. Therefore, we simply append Prog^^^ to the efF clause from the previous 
case. Similarly, the ensuring clause ensuring ^^^^ can also be simply conjoined with the the ensuring 

62 



transitions 



output 7r{vars ''^■, local vars '^ , ■ ■ ■ , vars ' " , localVars 
where Vi<.<„ (^^'^' A P^;f A P%) A P^'l 
pre Vi<.<„ {P'''''' A P^;f A Pref;f ' 
eff 

if ... 

elseif P^'^' A P„^f then Prog'';-;' 

elseif . . . 

fi; 



D,7r\ 



Prog'^n'' 

ensuring Ai<i<n l-^^'*^* A P'^^t^ ^ ensuring g^] A ensuring 



D,a A dC.-'^ ^ .^.^.^^-^.^.'^^ A .^.„,^„-^.'D.'f 



' «n 



Figure 7.7: General form of an output transition in tlie expansion of a composite automaton 

clause from the previous case. 

Note that, Prog^^^^ may, in fact, amount to a no-op in all executions. However, in general, 
this cannot be statically decided. Also note that the order of execution of the subsumed input 
transitions with respect to each other or to the enabled output transition does not matter. The 
semantic checks require that each conditional branch or for body executed in either the subsumed 
input transition or the remainder of the clause must be derived from distinct automata. These 
effects can alter only the value of state, local, or choose variables derived from the automaton 
contributing that effect. Furthermore, the effects can depend only on those same set of state, local, 
and choose variables or on the parameters of the transition. No effect can change a parameter 
value. 

We define Prog ^^^l to be the program in the eff clause that combines the effects of output 
transitions and subsumed input transitions. Similarly, we define ensuring ^^^l to be the predicate 
that appears in the ensuring clause. 

7.9 Expanding internal transitions 

The basic form of expanded internal transitions is analogous to that of output actions. The most 
significant difference is that the internal transition expansion must account for output actions that 
are (potentially) hidden. So before we consider the general expansion for internal transitions, we 
build on the discussion of the expansion of output transitions above to consider the the simpler case 
of expanding transitions for internal actions when there are no hidden clauses for those actions. 
We then discuss how to generalize this construction to account for hidden output transitions. 

Internal-only transitions 

The expanded form of the transition for an internal action when there is no hidden clause for that 
action follows a pattern similar to that of output transitions when there are no like-named input 
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transitions 



internal 7T{vars^''^; local vars^'^^ , ■ ■ ■ , vars^''-'^", localVars ''^) 



Where Vi<.<„, P^'^' A P.^f A Pf"'^ 



pre 

Vi<.<„ (^^'^^ A P.S-'^ A Pre^-) 
eff 
if ... 

elseif P^'^' A P^^t'^ A then Progf^f 
elseif . . . 
fi 

ensuring Ai<»<„ (P^'^' A P^^^'J^ ^ ensuring f^f 
Figure 7.8: Expanded transition for an internal action with no matching hidden clause 



transitions. In that expansion, shown in Figure 7.8 we introduce local variables for the parameters 



of each contributing automaton as well as all the local variables from all the contributing transitions. 
Following reasoning analogous to the output case, we use the conjunction of the component where 
clause P^'*^* of the contributing component and the signature where clause P^^i'^ as the guarding 
conjunction for selecting the contributing instance of the contributing component throughout the 
expanded internal transition. 

In the where clause, the guarding conjunction is paired with the component where clause 
for the contributing transition Pj„°i'^ to initialize the local variable values. In the precondition, 
the guarding conjunction is paired with the pre predicate of the contributing transition. In the 
eff clause, the guarding conjunction selects the conditional branch containing the effects of the 
single contributing transition that is defined for the given parameters. In, the ensuring clause, the 
contributing transition ensuring clause must be satisfied when the guarding conjunction holds. 

Internal transitions with hiding (general case) 

The most important difference between the expansion for internal transitions and that for output 
transitions is that the internal transition expansions must account for output actions that are 
(potentially) hidden. We cannot, in general, statically decide whether the hidden predicate H^''^ 
covers the output signature predicate Pout ■ ^°^ "^^^ ^^-i i^ general, statically decide whether 
H ''" covers the where clause for any contributing transition Po^t^t^ ■ Thus, each transition for each 
action n^vars ''^) mentioned by a hidden clause must be incorporated into the expanded composite 
automaton twice, once in an output transition and once in an internal transition. 

One way to do this, would be to include two internal transitions for each transition ir^vars ''^). 
The first transition would be derived as in the previous section, ignoring any hidden output actions. 
The second transition would be a second copy of the expanded output transition 7:{vars ''^). This 
transition would be identical to the general case output transition expansion except it would be 
labeled internal. 
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An alternative expansion is shown in Figure 7.9 This expansion follows the pattern of including 



just one transition of each kind. An advantage of having just one transition is that the expanded 



transition where clause trivially satisfies semantic proof obligation 4.5 and its only functional role 
is to define the initial values of the local variables. 



Proof obligations 7.3 and 7.4 imply that, over all components, at most one of the conjunctions 



pD,c, ^ -Pj„(''^ and P^'*^' A Po^t^ can be true. So these conjunctions are used as the guard- 
ing conjunctions for the expanded transition. The former guards elements derived from internal 
component transitions. The latter guards elements derived from output component transitions. 

In the where clause, each guarding conjunction is paired with the component where clause for 
the contributing transition -P^j^'Jj of matching kind to initialize the local variable values. Since a 
hidden output transition might also subsume a like-named input action, the where predicate also 
asserts -Pj„''^rj In the precondition, the guarding conjunction selects the appropriate component 
transition precondition Pre^^^ or Pre^^f to satisfy. These latter disjuncts are abbreviated by 
referencing the expanded output pre predicate Pre^^J . The eff clause selects the effects of the 
single contributing internal or output transition that is defined for the given parameters and then 
performs all the effects of the subsumed input transitions. The conditional selecting the effects of 
an internal action is shown in the figure. Effects derived from hidden output and hidden subsumed 
inputs are executed in the appended program Prog^^. Similarly, the ensuring clause from the 
previous case can be simply conjoined with expanded output transition ensuring clause ensuring ^^ 

Notice, it is a consequence of the expanded signature where clause P^nt^ that some value of 



vars 



^'^^ satisfies one of the guarding conjunctions. Furthermore, since component Ci satisfies 



the semantic proof obligation 4.4, there must exists a value for local variable Ci that satisfies 
the consequent whenever a guarding conjunction is true. Therefore, whenever the internal action 
Tr{vars ''^) is defined in the signature of DExpanded, the internal transition -K^vars '^) is also 



defined. Thus, DExpanded also satisfies semantic proof obligation 4.4 for internal transitions. 



'We cannot simply conjoin P^^^ to the transition where clause because P^^'^ would not distribute correctly. 
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transitions 



internal Tr{vars^''^; local vars^''^^ , ■ ■ ■ , vars^'^"- , localVars^''^) 

where Vi<.<„ ((^^'^^ A P.^^ A P.^l'X) V (p^'^' A P^ A P.^^O) ^ ^^i^. 



pre 

w (pD,C, A pC»,i- A PrpC'^''r^ v Prp^^'^ 

Vl<i<n l^-f^ '\ -f^int '^ ^'^int J ^ ^'^out 

efF 
if ... 

elseif P^'^» A P^^^'" A then Progf^i'' 
elseif . . . 

fi; 

Prog out 

ensuring Ai<i<„ {^P'"''^' A P^^^^^^ => ensurmg^^^ j A ensunng^^t 

Figure 7.9: General form of an internal transition in the expansion of a composite automaton 
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8 Expansion of an example composite automaton 



In this section, we detail the expansion the composite automaton introduced in Example 2.4 In this 
expansion, we apply the techniques described in Section [7] to the composite automaton Sys shown 



in Figure 2.4 and to the canonical versions of its component automata shown in Figures 6.3-6.5 



In Section 8.2 we derive the signature of SysExpanded in three stages. In Section 8.3 we describe 
the state of the expanded automaton, including its initial values, and an invariant about the scope 
of definition for its state variables. 

Where convenient, we recapitulate definitions developed in previous sections in summary tables 
to save the reader (and the authors!) from having to flip back to look up definitions. 



8.1 Desugared hidden statement of Sys 



Following the procedure described in Section [7. 2[ we eliminate terms other than variable references 
from the parameters of the hidden statement of automaton Sys by replacing params^^^^ = 

(nProcesses, nProcesses+1 , x:Int) with vars^^^'^®^^ = (nl : Int, n2: Int,m: Int), defining cr^*'^^ to 
map m:Int to a fresh variable i:Int, and rewriting the where clause in the hidden statement to 

produce 

hidden send(nl, n2 , m) 

where 3 i : Int (i = m A nl = nProcesses A n2 = nProcesses +1 ) 
which simplifies to 

hidden send(nl, n2 , m) where nl = nProcesses A n2 = nProcesses+1 
Thus, we define i^/'Sys.send ^.^ ^^ ^^ ^ nProcesses A n2 = nProcesses+1. 

8.2 Signature of SysExpanded 



To expand the signature of composite automaton Sys as described in Section |7.3[ we first calculate 
the per-kind, per-action, per-component predicates -P^j„^' "'^- Then we combine these by compo- 
nent to form the provisional kind predicates P^ov j^^^J^ . Finally, we combine these predicates with 

the hidden statement predicate to derive the signature predicates P-J ''^ , P^^j ''^ , and P^J^ '^ . 
In computing these predicates it is helpful to remember the component predicates and canonical 



variables of the sample composite automaton Sys. Table 8.1 collects the former from Example 2.4 



Table 8.2 recalls the latter as they were defined in Example 6.2 The local variables shown are 



derived from Example 6.2 as described in Section 7.6 



PREDICATE 


VALUE 


pSys.C 


j = i+1 A 1 < i A i < nProcesses 


pSys,P 


1 < n A n < nProcesses 


pSys.W 


true 



Table 8.1: Component predicates of the sample composite automaton Sys 



Actions per component 

First, we define predicates for each kind of each action for each component. Sys has three compo- 
nents and four action names, each of up to three kinds. Thus, there are thirty-six possible per-kind. 
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CANONICAL SEQUENCE 


VARIABLES 


vars^'^^ 


nProcesses:Int 


n 

vars 


n: Int 


vars^ 


n:Int 


uarsSys.send 


nl:Int, n2:Iiit, m:Int 


^^^^Sys,receive 


nl:Int, n2:Int, m:Int 


mrsSys.overflow 


il:Int, s: Set [Int] 


^^^gSys.found 


il:Int 


/om/FarsSys-overflow 


P: Map [Int, Locals [P, overflow]], 
W: Locals [Watch, Int, overflow] 



Table 8.2: Canonical variables used to expand the sample composite automaton Sys 



per-action, per-component predicates PfJ j "'^. Table 8.3 shows the seven of these predicates that 



are not trivially false. All the existential quantifiers have been eliminated from the predicates shown 
in the table. 

We can simplify such a predicate by dropping existential quantifiers and conjuncts that are 
superfluous. A quantifier is superfluous if the predicate equates the quantified variable directly 
with a term not involving a quantified variable. The conjunct that equates the quantified variable 
to a defining term is also superfluous. The simplification proceeds in four steps: 

1. Define a substitution that maps any superfluous existential variables to the corresponding 
term. 

2. Apply the substitution to the predicate. 

3. Delete identity conjuncts from the where clause. 

4. Delete the existential quantifiers for variables that no longer appear in the predicate. 



For example, by the definition given in Section 7.3 



^Sys.Csend __^ aws^y^'C (P^ys-C ^ pC.send^ 

= 3 n:Int (1 < n A n < nProcesses A nl 



n A n2 



n+1) 



We simplify this predicate by defining and applying a substitution that maps n:Int to nl:Int, 
delete the resulting identity conjunct, the quantified variable, and the quantifier, resulting in the 
predicate shown in Table |8.3[ 



Provisional action kinds 

Since no two components of Sys share the same kind of any action, it is simple to define the 
provisional kind predicates P^0Vf.^^J^ . Seven of the twelve possible predicates are not trivially 

false. Each of these has exactly one nontrivial disjunct — the corresponding predicate P^J^j^ "'^ 
shown in Table 18.41 



as 
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Predicate 


VALUE 


pSys,C,send 

in 


(1 < nl A nl < nProcesses) A (n2 = 


= nl+1) 


pSys,P,send 


(1 < nl A nl < nProcesses) A (n2 = 


= nl+1) 


pSys.C, receive 


(1 < nl A nl < nProcesses) A (n2 = 


= nl+1) 


pSys,P, receive 


(1 < n2 A n2 < nProcesses) A (nl = 


= n2-l) 


pSys.P, overflow 


1 < il A il < nProcesses 


pSys.W, overflow 

in 


il G betweend, nProcesses) 


pSys,W, found 


il e betweend, nProcesses) 



Table 8.3: Simplified predicates defining contributions to the signature of Sys 



Predicate 


VALUE 


„ Sys, send 


pSys,C,send 

in 


„ Sys, send 


pSys,P,send 


„ Sys, receive 
Prov^it 


pSys.C, receive 


„ Sys, receive 


pSys.P, receive 

in 


„ Sys, overflow 
Prov^it 


pSys,P, overflow 
"out 


„ Sys, overflow 


pSys.W, overflow 

in 


n Sys, found 
Prov^it 


pSys,W, found 



Table 8.4: Provisional where predicates for the signature of Sys 
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Signature predicates 

We now compute the nontrivial signature predicates Pj„ ''^, P„„( ''^, and P^^^ ''^ for the four action 
labels send, receive, overflow, and found of automaton SysExpeinded. 

Output actions We compute the signature predicate for output action send, by applying the 
formula 

^Sys,send^^^^^Sys,P,send ^ ^^Sys.send^ 



7.2 



we 



find that P^r^-' 



Using the desugared form of the hidden predicate shown in Example 

is 

1 < nl A nl < nProcesses A n2 = nl+1 

A ^(nl = nProcesses A n2 = nProcesses +1 ) 

Computing the predicates for output actions receive, found, and overflow is simple because 

there is no hidden clause applying to them (i.e., H y^'^ is false) and the action predicate is, in 

fact, just the provisional kind predicate, as shown in Figure [8?T| 

Input actions We compute the signature predicate for input action send by applying the formula 

nSvs.send „ Svs.send . r^ Svs.send 
PJ = ProVi^ A ^Prov^'^t 

Thus, Pj„ ' evaluates to 

1 < nl A nl < nProcesses A n2 = nl+1 A 

^((1 < nl A nl < nProcesses) A (n2 = nl+1)) 
The signature predicates for input actions receive, and overflow are computed similarly and 



appear in Figure 8.1 



Internal actions In Example 2.4, the component automata have no internal actions. Therefore, 

Svs S6rid 
the only internal action in Sys is the hidden action send. Thus, the predicate P-^^ ' is equivalent 

to 

Provll!''''"' A FSy-'^^'^^ 
which evaluates to 

1 < nl A nl < nProcesses A n2 = nl+1 A nl=nProcesses A n2=nProcesses+l 



The complete expanded signature of automaton Sys is given in Figure 8.1 



8.3 States and initially predicates of SysExpanded 



The complete expanded state of automaton Sys is given in Figure 8.1 Since each component of the 
desugared composite automaton has non-type parameters, all three state variables are maps. Three 
of the initially subclauses (and the subsequent invariant) assert the well-formedness requirement 
that each map is defined only for values of the component parameters on which the component itself 
is defined. The other three initially subclauses assert that the contents of each channel is initially 
empty, the watch process is looking for values between 1 and nProcesses and that each process P 
initially has value and nothing to send. The type declaration appearing at the beginning of the 
figure is the automatically generated sort for the state of the composite automaton. 
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type States[Sys] = tuple of C:Map[Int, States [Channel , Int , Int ]] , 

P:Map[Int, States[P]], 
W : States [Watch , Int] 

automaton SysExpanded(nProcesses : Int) 
signature 

output sendCnl, n2 , m:Int) 

where 1 < nl A nl < nProcesses A n2 = nl+1 

A ^(nl = nProcesses A n2 = nProcesses +1) , 
receiveCnl, n2 , m:Int) 

where 1 < nl A nl < nProcesses A n2 = nl+1, 
overflow ( il : Int , s: Set [Int]) where 1 < 11 A 11 < nProcesses, 
f ound ( 11 : Int ) where 11 G betweenCl, nProcesses) 
input sendCnl, n2 , m:Int) 

where 1 < nl A nl < nProcesses A n2 = nl+1 

A ^(1 < nl A nl < nProcesses A n2 = nl+1), 
receiveCnl, n2 , m:Int) 

where 1 < n2 A n2 < nProcesses A nl = n2-l 

A ^(1 < nl A nl < nProcesses A n2 = nl+1), 
overflow ( 11 : Int , s:Set[Int]) 

where 11 e betweenCl, nProcesses) 

A ^Cl < 11 A 11 < nProcesses) 
internal sendCnl, n2 , m:Int) 

where 1 < nl A nl < nProcesses A n2 = nl+1 

A nl = nProcesses A n2 == nProcesses+1 
states C:Map[Int, States [Channel , Int, Int]], 
P:Map[Int, States[P]], 
W: States [Watch , Int] 
initially 

V n:Int CCl < n A n < nProcesses) => C [n] . content s = {}) 
A V n:Int CCl < n A n < nProcesses) <=> definedCC, n)) 

A V n: Int CCl < n A n < nProcesses) ^P[n].val = A P[n].toSend = {}) 
A V n:Int CCl < n A n < nProcesses) ^ definedCP, n)) 
A W.seen = constant C false ) 

invariant of SysExpanded : 

V n : Int Cl < n A n < nProcesses <^ def Ined CC [n] ) ) ; 

V n : Int Cl < n A n < nProcesses <^ def ined CP [n] ) ) 



Figure 8.1: Expanded signature and states of the sample composite automaton Sys 
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8.4 Input Transition Definitions of SysExpanded 



We compute the input transitions of SysExpanded by following the pattern of Figure 7.3 for each of 



the input actions in its signature (receive, send, and overflow) and simplifying. Figure 8.2 shows 
the three resulting forms. 

In that figure, each input transition is formed from only a single contributing component. 



Thus, the conjunctions in the where over the contributing components in Figure 7.3 each resolves 
to a single term. Furthermore, we omit the where clauses for the receive and send transitions 
because the transition definitions have no local variables. In each of the three transitions, we 

omit the ensuring predicate altogether because the sole contributing predicate for each transition 

/ • P, receive • C,send , • W,overf low\ ■ , ■ • n , mi it i r i 

[ensuring j^^ , ensuring-^ , and ensuring ^^ j is triviahy true, i he eft clause of each 

transition resolves to a single for loop or conditional. In the overflow transition, the conditional is 

replaced by its body because there is only a single contributing transition. 



Figure 8.3 shows the final text of the expanded input transitions. In that figure, we omit 
the local variable P:Map[Int, Locals [P, overflow]] from the overflow transition because it does 
not appear in the transition precondition or effects. The where clause predicate -Pj„ j ' ' 

because vars^^' is empty and p^y^^'" is trivially 



8.5 



reduces to the implication shown in Table 
true. 

The for loops in the receive and send transitions have been eliminated by the following simpli- 



fication. Filling in the specified variables from Tables 8.2 predicates from Tables 8.1 and|8.5|and 



statements from Example |6.2| in the receive transition for loop yields the loop 

for n:Int where (1 < n A n < nProcesses A nl = n-1 A n2 = n) do 
if P [n] . val = then P [n] . val := m 
elseif m < P[n2].val then 

P[n].toSend := insert (P [n] . val , P [n] . toSend ) ; 
P [n] . val := m 
elseif P [n] . val < m then 

P[n].toSend := insert(m, P[n].toSend) 
fi 
od. 
Since the last conjunct of the loop where clause limits the loop variable to a single value, the 
transition parameter n2, we can eliminate the loop altogether. Thus, in Figure [8^ we replace the 
loop with its body after applying to the body a substitution that maps the loop variable n to its 
value n2. Similarly, the for loop in the send transition is eliminated using a substitution that maps 
its loop variable n to the transition parameter nl. 



8.5 Output Transition Definitions of SysExpanded 



We compute the output transitions of SysExpanded by following the pattern of Figure 7.7 for each of 



the output actions in its signature (receive, send, overflow, and found) and simplifying. Figure 8.4 
shows the four resulting forms. 

Notice that only one component contributes an output transition to each expanded output tran- 
sition. Therefore, only syntactic elements from the sole contributing component and the correspond- 
ing expanded input action appear in each transition. Each local variable list contains of the compo- 
nent variables for that contributing component. Since, /oca/ Vars ^^'^^^^'''^^, localVars y^'^®^ , and 
localVars ^^' °^^ are empty, they are omitted from their respective transitions. Since component 
W is unparameterized, the found transition has no local variables at all. 

The where clause of each transition resolves to a single term rather than being a disjunction 
over the contributing components. Furthermore, we omit the where clauses for the receive, send. 
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PREDICATE 


VALUE 


pP, receive 

in 


nl = n-1 A n2 = n 


pCsend 

in 


nl = n A n2 = n+1 


pW,overf low 

in 


il G betweend, nProcesses) 


pW,overf low 

^in,ti 


s = W.s2 U {11} V ^(11 e s) 


pSys,W, overflow 

in,ti 


11 e betweend, nProcesses) => (s 


= W.s2 U {11} V ^(1 


1 e s)) 



Table 8.5: Nontrivial predicates used in expanding input transition definitions of tlie sample com- 
posite automaton Sys derived from Figures 6.3[ 6.4 and 6.5 



input recelve(mrsSys,recelve^ 

eff for mrsSys.P where pSys,P ^ pP.recelve ^^ p^^^P,recelve^^ 

input send(warsSys,send) 

eff for vars^y^'^ where P^ys.C ^ pff^""^ do Prog^f^""^ od 

input overflow(mrsSys,overflow. i^cal /om/I/arsSys.°^erf low^ ^^^^^ ^Sys,W,overf low 

rr n W, overflow 
eff Prog,^ 

Figure 8.2: Form of input transitions of SysExpanded 

input receive (nl, n2 , m) 

eff if P[n2].val == then P[n2].val := m 
elseif m < P [n2] . val then 

P[n2].toSend := Insert (P [n2] . val , P [n2] . toSend) ; 
P [n2] . val := m 
elseif P[n2].val < m then 

P[n2].toSend := insert(m, P [n2] . toSend) 
fi 

input sendCnl, n2 , m) 

eff C [nl ]. content s := insertCm, C [nl ]. content s ) 

input overf low ( 1 , s ; locals W : Locals [W , Int , overflow] ) 

where 11 e betweend, nProcesses) =^ ( s = W.s2 U {11} V ^(11 G s)) 
eff if s = W.s2 U {11} then W.seen[ll] := true 
elseif ^(11 e s) then W.seen[il] :— false 
fi 



Figure 8.3: Input transition definitions of SysExpanded 
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PREDICATE 


VALUE 


pC, receive 
^out 


nl = n A n2 = n+1 


pC, receive 

^out,ti 


nl = n A n2 = n+1 


p C, receive 


m e C[n] .contents 


pP,seiid 
^out 


nl = n A n2 = n+1 


pP,send 

^out,ti 


nl = n A n2 = n+1 


p P.send 
^^'^out 


m e P[n] .toSend 


pP, overflow 
^out 


il = n 


pP, overflow 

"out,ti 


il = n 




s = P[n] .toSend A n < size(s) A P[n] .t C s 


pW, found 
^out 


il e betweenCl, nProcesses) 


p W, found 
-f"^'"^ out 


W. seen[il] 



Table 8.6: Nontrivial predicates used in expanding output transition definitions of tlie sample 



composite automaton Sys derived from Figures 6.3, 6.4 and 6.5 



and found transitions because the transition definitions have no local variables. Similarly, the en- 
suring clause is only a single conjunction. In each of the four transitions, we omit the ensuring 



predicate altogether because the consequent for each transition {ensuring ^'^^ , 



P.send 
ensuring ^'^t 

ensuring g'^f , and ensuring ^'^^ ) is trivially true. Furthermore, the conditional and guard- 

ing conjunction can be omitted from the eff clause because only one output contributes. So each 
effect is just the effect of the contributing output transition followed by the effect of the corre- 
sponding expanded input transition. Since the output transition definition for the found action in 
component W has no effect and there is no found input action, the expanded found transition has 
no effect either. 



Filling in the specified variables from Tables 8.2 predicates from Tables 8.1 and 8.6 and state- 



ments from Example 6.2 and Figure 8.3 yields the complete the complete text of the expanded 



output transitions shown in Figure 8.5 We simplify the transition definitions using two techniques. 
First, we eliminating unneeded local variables. Second, we use the fact that the signature where 

Cttq t ("* r* p i Tr o 

predicate for an action (e.g., P^^j ' ) is implicitly conjoined to the corresponding transition 

where predicate (e.g., Pj.tl, ) and precondition (PreJ.t ' ) to eliminate redundant 



out,ti 



assertions in the transition where predicate and precondition. The resulting final form of output 



transitions is shown in Figure 8.6 



To eliminate unneeded local variables, we follow the four step process to eliminate unneeded 



local variables described in Section 4.2 For example, we note that the where clause of the receive 



transiting equates n with parameter nl. Furthermore, there is no assignment to n in the effects of 
that transition. Thus, the local variable n is extraneous. So, we define a substitution that maps 
the local variable n to the parameter nl and apply it to the where, pre, and eff clauses. We then 
delete the resulting identity conjunct from the where clause and the declaration of the local variable 
n. Similarly simplifications eliminate the local variable n from the send and overflow transition 
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output receive(uarsSys.receive. ^^^^^ yars^y^'^) 

u nSvs C A nC, receive . nC, receive . ^Sys, receive 

where P^y^'^ A P^,'^ A P^^^^^^ A P^^\ 

nSvs C A nC, receive . n C, receive 
pre P^y^'^ A P„„i A Pre^:^t 

rn r> C, receive 
efF Prog^'^t ; 

„ Svs, receive 
ProQir! 



output seiid{vars^y^'^^^^; local vars^^^'^) 

where P^ys.P a P^^f^^ A PSf" ^ P^''"' 



pre pSys,P A p!;,^^ A Pre^^f ^^ 



rr n P.send 
efF Prog^'^t ; 

„ Svs, send 
Pro^.J' 



output overflow(warsSys,overflow. i^^.^! i,areSys.C^ ^^^gSys,?^ ^^^^^y^^^Sys.overf low^ 

wVioT-o pSys.P A pP.overflow pP.overflow pSys,overf low 
wneie r ■> /\ r^^^ /\ r^^^^^^ /\ -r^„^j^ 

pre pSy-'P A Pr„?^^^^^°^ A Pre^^f^^^l"^ 
rn n P, overflow 

„ Sys, overflow 
Progy 

output f ound(warsSy^'f °™^) 

pre pSy-.W ^ pW,f ound ^ p^^W-f o^^d 

Figure 8.4: Form of output transitions of SysExpanded 

definitions. Since the resulting receive and send transitions no longer have any local variables, we 

omit their where clauses altogether. 

After this simplification, the precondition for the receive transition is 

pre 1 < nl A nl < nProcesses A n2 = nl+1 A m G C[nl] . contents 

However, the first three conjuncts are also asserted by the the signature where clause for the receive 

Svs rscGivs 
output action P^^j ' and, therefore, are redundant. Similarly simplifications to the where 

and pre clauses of the other transitions result in the final text of the expanded output transitions 



shown in Figure 8.6 



8.6 Internal Transition Definitions of SysExpanded 

Since no component has any internal transitions, the only internal transitions in SysExpanded is the 
hidden output send transitions. In the case where no component contributes an internal transition. 



the form in Figure 7.9 reduces exactly that in Figure 7.7 That is, the internal send transition 
definition is identical to the output transition definition except for its label. The two actions are 
distinguished exactly by the assertion or negation of /fSys,send j^^ ^^^ signature of SysExpanded. 
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output receiveCnl, n2 , m ; local ii:Int) 

where 1 < nl A nl < nProcesses A nl = n A n2 = nl+l 
pre 1 < n A nl < nProcesses A nl = n A n2 = n+1 

A m G C [n] . content s 
eff 

C [n] . content s := delete(m, C [n] . content s ) 
if P[n2].val = then P[n2].val := m 
elseif m < P[n2].val then 

P[n2].toSend := insert (P [n2] . val , P [n2] . toSend ) ; 
P [n2] . val := m 
elseif P [n2] .val < m then 

P[n2].toSend := insert (m, P [n2] . toSend) 
fi 

output sendCnl, n2 , m ; local n:lnt) 

where 1 < n A n < nProcesses A nl = n A n2 = n+1 
A nl == n A n2 = n + 1 
pre 1 < n A n < nProcesses A nl = n A n2 = n+1 A m G P[n]. toSend 
eff 

P[n]. toSend := delete(m, P[n]. toSend) 

C [nl] . content s := insert(m, C [nl ]. content s ) 

output overflow(il, s; local n : Int , 

P:Map[Int, Locals[P, overflow]], 
W : Locals [Wat ch , Int, overflow]) 
where 1 < n A n < nProcesses A il = n A 

il e betweenCl, nProcesses) ^ (s = W.s2 U {il} V ^(il G s)) 
pre 1 < n A n < nProcesses A il = n A 

s = P[n]. toSend A n < size(s) A P [n] . t C s 
eff P[n]. toSend := P [n] . t 

if s = W.s2 U {il} then W.seen[il] := true 
elseif ^(il G s) then W.seen[il] := false 
fi 

output found(il) 

pre il G betweend, nProcesses) A W.seen[il] 



Figure 8.5: Output transition definitions of SysExpanded 
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output receive (nl, n2 , m) 
pre m e C [nl] . contents 
eff 

C [nl ]. contents := delete(m, C [nl] . content s ) 
if P[n2].val = then P[n2].val := m 
elseif m < P[n2].val then 

P[n2].toSend := insert (P [n2] . val , P [n2] . toSend ) ; 
P [n2] . val :== m 
elseif P [n2] .val < m then 

P[n2].toSend := insert (m, P [n2] . toSend) 
fi 

output sendCnl, n2 , m) 
pre m e P[nl]. toSend 
eff 

P[nl]. toSend := delete(m, P [nl ]. toSend) 

C [nl] . content s :— insert(m, C [nl ]. content s ) 

output overflow(il, s; local P:Map[Int, Locals [P, overflow], 

W : Locals [Wat ch , Int , overflow]) 
where s = W.s2 U {11} V ^(il G s) 

pre s = P[il]. toSend A 11 < size(s) A P[il].t C s 
eff P[il]. toSend :== P[il].t 

if s = W.s2 U {11} then W.seen[il] := true 
elseif ^(11 e s) then W.seen[il] := false 
fi 

output found(il) 
pre W . seen [11] 



Figure 8.6: Simplified output transition definitions of SysExpanded 
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internal send(nl, n2 , m) 
pre m S P[nl] .toSend 
eff 

P[nl].toSend := delete(m, P [nl ] . t oSend) 

C [nl] . content s := insert(m, C [nl ]. content s ) 



Figure 8.7: Internal transition definitions of SysExpanded 



Tlie final transition of SysExpanded is shown in Figure 8.7 
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9 Renamings, Resortings, and Substitutions 

In this section, we give formal definitions for resortings and variable substitutions in lOA. 
9.1 Sort renamings 



A sort renaming or resorting is a map from simple sorts to sorts, ^^ Any resorting p extends 
naturally to a map p defined for all simple sorts by letting p be the identity on elements not in the 
domain of p. In turn, p extends further to a map p from sorts to sorts by the following recursive 
definition: 

I piT) if li is a simple sort T, and 

p{u) ::= < 

I T[p(Ti), . . . , p{Tn)] if u is a compound sort T[ri, . . . , T„]. 

Let ps—,T denote a resorting that maps the sort S to sort T and is otherwise the same as p 
(even if S is already in the domain of p) . 

9.2 Variable renamings 

A variable renaming pq is an extension of a resorting p that maps variables in a sequence q to 
distinct variables. If u is a variable i:T in g, then Pq{v) is defined to be j'-p{T) where j is an 
identifier (i itself, if possible) such that j:'p{T) ^ Pq{v') for all variables v' that precede v in q. We 
say that pq is a variable renaming with respect to precedence sequence q. 

If pr is a variable renaming where r = q\\p then we say pr is an extension of pq with respect to 
precedence sequence p and we write that pr = Pq^ p- 

9.3 Operator renamings 

An operator renaming u; is a map from operators to operators that preserves signatures. Any 
operator renaming iv extends naturally to a map uj defined for all operators by letting uj map each 
operator not in the domain of co to itself. 

We extend any operator renaming u further to a map d) on some syntactic elements of an lOA 
automaton (terms to terms, statements to statements, etc.) We now define Co for each type of lOA 
syntax to which it may apply. 

Terms and sequences of terms 

If n is a term, then a)(u) is 

• f , if u is a variable v, 

• u;(/)(a)(ni), . . . ,d)(n„)), if u is a term /(ui, . . . ,Un) for some operator / and terms ui, . . . ,Un, 

• Vt" u){u'), if li is a term \/v (u') for some variable v and term u' , and 

• 3v Co{u'), if li is a term 3v {u') for some variable v and term u' . 

If g is a sequence of terms {ui,U2, . . . , n„}, then d)(g) is {cij(ui),d)(n2), . . . ,a)(u„)}. 



^^In lOA, sorts are divided into simple or primitive sorts, such as Int and T, and compound or constructed sorts, 
such as Set [T] and WeightedGraph[Node ,Nat] . 
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Values 

If / is a value, then uj{l) is 

• CL'(t), if / is a term t 

• choose V ■where LJ{p), if / is a choice choose v ■where p for some variable v and predicate p. 

Statements and programs 

If s is a statement, then Ci)(s) is 

• LJ(lhs) := ij{rhs), if s is an assignment Ihs := rhs for some lvalue Ihs and some value r/is, 

• if iv{pi) then uj{si) elseif oo{p2) then... else u{sn) fi, if s is a conditional statement 
if pi then si elseif p2 ■ ■ ■ else Sn fi for some predicates pi, . . . ,Pn-i and statements si, . . . , Sn, 
and 

• for V ■where ui^p) do io{g) od, if s is a loop statement for v ■where p do g od for some 
variable v, predicate p, and program g. 

If (7 is a program si; S2; . . . , then ci)((7) is a)(si);d)(s2); • • ■ • 

Shorthand tuple sort declarations 

If to is an operator renaming and di and d2 are t^wo shorthand tuple sort declarations: 

di ::= T tuple of ii:Ti, i2:T2, . . . ,and 
<i2 ::= T tuple of ji:ri,J2:T2,. .., 

where ii, ^2) • • • > and ji, j2, . . . , are identifiers and T, Ti, T2, . . . , are sorts then ■we ■write u!di^d2 or 
'^T,{ii.i2,...}^{jij2---} ^°^ *^^ operator renaming that maps 

1. tuple selection operators —ik'.T -^ T^ to jk'-T -^ T^, and 

2. tuple set operators setJ^rT, T^ — > T to set_jk:T,Tk — > T. 

9.4 Renamings for automata 

In Section|5j^we defined resortings that map types to actualTypes ' for some desugared automaton 
A ■with formal type parameters types instantiated ■with actual type parameters actualTypes ' . 

Let p be such a resorting and g be the variable renaming pn. We extend ^ to a map g on 
some syntactic elements of an lOA automaton (terms to terms, statements to statements, etc.) by 
defining g for each type of lOA syntax to ■which it may apply. 

Automata 

If A is desugared primitive automaton ■with syntax as given in Section |4] and sho^wn in Figure 4.5 
then g{A) i: 
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^® Strictly speaking, the definition of tfie automaton g{A) is not a legal definition of a primitive lOA automaton. Its 
type parameters, shown as types , should really consist of the non-built-in types that appear in sorts in g{types ). 
Furthermore, the declared state variables may not match the aggregate state variable selectors that appear in terms 
in signature "where clauses, in the initially clause, or in transition definitions. 
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automaton A{g {vars ); types ) 
signature 



kind TT{g^''^{vars^''^)) where q^''^{P 



kind' 



states p{stateVars^) := Q'^{initVals^) initially g'^iP^n) 
transitions 



•A,7r 
^kind,ti 



kind TT{vars^''"] local localVars f^^^) where Pf,^^^ 



kind,tt 



pre Prek-nd,t, 

eff Progf^L. ensuring ensuringf^^. 



where 



1. g is a variable renaming g h {{A, A':States[A, types^ 

2. g ''^ is a variable renaming g h vars ''". 



■A/K 



3. g^l^^ I is a variable renaming 



g ''" \- (\A,A:Locals\A^types\kind^T:\W localVars 



A,n 



vars 



stateVars \\ postVars^ 
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A,TT 



kindW ^ocalPostVarsl^^^, 
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Transition definitions 

Let i be a transition definition in automaton A as given above. That is, t is 

kind Tr{vars^''^ ; local localVars j^-^^^^) case c where pi 
prep2 
eff g ensuring p^ 

where vars ''^ is a sequence of variables, localVars j^^^^ = {ii:Ti,i2:T2, . . . ,} is a sequence of vari- 
ables, pi, p2i and p3 are predicates, and g is a program. Let S be the aggregate local sort 
Locals[A,types ,kind,7r] of t, and g be the variable renaming gj.^^^ ^ given above. That is, g 



is an extension of p with respect to the precedence sequence {A, A' -.States [A, types ^ 



vars 



stateVars \\ postVars' 



vars 



A,-IT\ 



{A, A':Locals[A, types , kind, vr] 



localVars^^^J localPostVars^l^^. 



■^''Even though variables in stateVars and postVars do not appear in any terms in a desugared automaton 
definition, we include those variables in the precedence sequence to ensure that selectors for local variables do not 
clash with selectors for state variables in transition definitions (see below). 

^®Like state variables, variables in localVars j,^^^ and localPostVars /.^^^ do not appear in any terms in a desugared 
automaton definition. We include those variables in the precedence sequence only to ensure that selectors for local 
variables do not clash with each other, (see below). 
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We define Q{t) to be 

kind 7r(^(mrs^'''); g{localVars ^.^^^)) case c where cJp(5),{n,j2,...}^{ji,J2,...}(^(Pi)) 
preCbp(^S),{h,i2,...}^{n,J2,-}i^iP2)) 
efF '^p{s),{iui2,...}^{juj2,-}i^i9)) ensuring ^p(s),{h,i2,...}^{n,J2,-}i^iP^))- 

where g{localVars j^-^^) is a variable sequence {ji:p{Ti),J2:p{T2), ...,}. Note that if localVars ^^^^ = 
g{localVars 1^-^^) , then i^p(s),{ii,i2,...}^{ji,j2,---} ^^ *^^ identity operator renaming. 

Statements and programs 

If s is a statement and g is some variable renaming, then g{s) is 

• g(lhs) := g{rhs), if s is an assignment Ihs := rhs for lvalue Ihs and value rhs, 

• if g{pi) then g{si) elseif £1(^2) then... else g{sn) fi, if s is a conditional statement 
if pi then si elseif P2 ■ ■ ■ else s^ fi for some predicates pi, ■ ■ ■ ,Pn-iand statements si, . . . , Sn, 
and 

• for g'{v) ■where ^'(p)do g'{g) od, if s is a loop for v ■where p do g od for some variable v, 
predicate p, and program g, where g' = gh {v}. 

If (7 is a program si; 82] ■ ■ ■ , then ^(g) is g{si); g{s2); ■ ■ ■ ■ 

Values 

If Hs a value and g is some variable renaming, then g(l) is 

• g{t), if / is a term t, and 

• choose g'{v) ■where g'{p), if Hs a choice choose v ■where p for some variable v and predicate 
p, where g' = g^ {f}. 

Terms and sequences of terms 

If n is a term and g is some variable renaming, then g{u) is 

• g{v), if li is a variable w, 

• /(^'(^i)) • • • ) Q^'^n))-, if n is a term /(ui, . . . , Un) for some operator / and terms ui, . . . ,Un, 

• yg'{v) g'{u'), if u is a term \/v {u') for some variable v and term n', where g' = g^ {v}, and 

• 3g'{v) g'{u'), if u is a term 3v {u') for some variable v and term n', where g' = g^ {f}. 
If g is a sequence of terms {ui, U2, . . . , Un}, then g[q) is {g{ui), g{u2), • . . , g{un)}- 
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9.5 Substitutions 

A substitution is a map from variables to terms such that the image of any variable has the same 
sort as the variable. Any substitution a extends naturally to a map a defined for all variables by 
letting & map each variable not in the domain of o" to a term that is a simple reference to the 
variable itself. 

Let o"t,_>t denote a substitution that maps the variable v to the term t and is otherwise the same 
as a (even if v is already in the domain of a). We extend any substitution a further to a map a 
on some syntactic elements of an lOA automaton (terms to terms, statements to statements, etc.). 
We now define a for each type of lOA syntax to which it may apply. 

Terms and sequences of terms 

If u is a term, then d'{u) is 

• o"(v), if u is a variable v, 

• /(cj(mi), . . . ,a{un)), if ti is a term f{ui, . . . ,Un) for some operator / and terms ui, . . . ,Un, 

• Vtf a^^uj^u'), if ti is a term \/v {u') for some variable v and term u', where itJ is a variable {v 
itself, if possible) with the same sort as w, where w J-V{(t{v')) for all variables v' G jrv(ii), 
and 

• 3w C7j,^^(n'), if li is a term 3v {u') for some variable v and term u', where w is as above. 
If g is a sequence of terms {ui, U2, . . . , n„}, then a{q) is {cj(iii), cJ(u2), . . . ,iT(ti„)}. 

Values 

If / is a value, then (t{1) is 

• o"(t), if / is a term t 

• choose w ■where (Tj,__>^(|)), if Z is a choice choose v ■where p for some variable v and 
predicate p, where w is a variable {v itself, if possible) with the same sort as v, and where 
w TV{a{v')) for all variables v' G TV {I). 

Statements and programs 

If s is a statement, then '(t{s) is 

• a{lhs) := a{rhs), if s is an assignment Ihs := rhs for some lvalue Ihs and some value rhs, 

• if (t(pi) then cJ(si) elseif (t{p2) then... else o"(s„) fi, if s is a conditional statement 
if pi then si elseif p2 • • .else s„ fi for some predicates pi, . . . ,Pn-i and statements si, . . . , Sn, 

• for w ■where (Jv^wip) do '&v~^w{g) od, if s is a loop statement for v ■where p do g od for 

some variable u , predicate p, and program </, where tt; is a variable {v itself, if possible) with 
the same sort as v, where w J-V{(j{v')) for all variables v' G J-V{s). 

If (7 is a program si; S2; • • • , then a{g) is cj(si); 0"(s2); • • • • 
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Transition definitions 

If, in automaton A parameterized by type parameters types , t is a transition definition 

kind TT^params'^; local vi,V2, ■ ■ ■) case c ■where pi 
prep2 
efF g ensuring p^ 

where params^ is a sequence of terms, vi,V2, ■ ■ ■ is a sequences of variables ii'-Ti, ^2:^2, . . . , pi, p2, 
and P3 are predicates, g is a program, and S is the aggregate local sort of t, then a{t) is 

kind 7r(o-{„^_„2_...}^|^j^^2,-}(P"™"^'^'')' ^ocal wi,W2, ■ ■ ■) 

case c where (I'5^{ij^i2,...}-^{ii,J2,...}('^{^i,i;2,.-}-»{«'i,«'2,.-}(Pi))) 
pre ws,{i,,i2,...}^{ji,J2,-}('^{i'i,f2,--}^{«'i,«'2,.-}(P2))) 

efF ^S,{h,i^,... }->{ii,J2,... } i'^{vi,V2,... }~^{wuW2,...}{9))) 

ensuring c:05_|j^^j2,...}^{ji,J2,...}('^{i'i,f2,...}^{«'i,«'2,.-}(P3))) 
where 

1. tt;^ is a variable jk'-Tk {vk itself, if possible), and 

2. Wk FV{a{v')), for ah variables v' £ {A, A':States[A, types'^]} U stateVars^ U postVars^ U 
vars U !FV{params'^) U {A, y4':Loca/s[yl, types , kind, it, c]} U {t'i,w^ | ^ < k^- 

Note that if i^ = jk for all fc, then 0Js^{i^^i2,...}^{jx,j2,--} ^^ *^^ identity operator renaming. 

Hidden clauses 

If c is a clause in a hidden statement 

TT{params^) where p 
where params^ is a sequence of terms and p is a predicate, then a{c) is 

7r(o-{^i,j,2,... }^{wi,w2,...}iP0-rams'^) . . . where o-j^j^^^,-. }^{«)i,«'2,.- }(^) 
where 

1. f fe is a variable ik'-Tk £ J^V{params^) 

2. tt;fc is a variable {vk itself, if possible) with sort Tk 

3. Wk J-V^a^v')) for all variables v' G TV{params'^) U .7-"V(p) U {f/ | I 7^ A;}. 

9.6 Notation 

Except in definitions such as these, we do not employ separate notations for the extensions p, p, 
Pu;, Pq, and ^ of a resorting p. In particular, when applying a resorting p to an lOA automaton A, 
we write p for g. Similarly, we do not distinguish a and a from a substitution a and we write a for 
a. 
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